From owner-xfs@oss.sgi.com Wed Jan 2 05:16:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jan 2008 05:16:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m02DGLIV005036 for ; Wed, 2 Jan 2008 05:16:24 -0800 X-ASG-Debug-ID: 1199279794-27d800000000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from welcomes-you.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2849A12250B1 for ; Wed, 2 Jan 2008 05:16:34 -0800 (PST) Received: from welcomes-you.com (welcomes-you.com [85.214.50.128]) by cuda.sgi.com with ESMTP id Gt2BSU2YCeKFdkDy for ; Wed, 02 Jan 2008 05:16:34 -0800 (PST) Received: from [130.75.117.49] (helo=[10.117.96.105]) by welcomes-you.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.62) (envelope-from ) id 1JA3SO-0007w5-HC; Wed, 02 Jan 2008 14:16:31 +0100 Message-ID: <477B8EAB.8000703@welcomes-you.com> Date: Wed, 02 Jan 2008 14:16:27 +0100 From: Carsten Aulbert User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8pre) Gecko/20071022 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: xfs@oss.sgi.com X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-ASG-Orig-Subj: How to damage a XFS-Filesystem? Subject: How to damage a XFS-Filesystem? X-SA-Exim-Version: 4.2.1 (built Tue, 20 Jun 2006 01:09:49 +0000) X-Barracuda-Connect: welcomes-you.com[85.214.50.128] X-Barracuda-Start-Time: 1199279797 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38365 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5339/Wed Jan 2 02:52:11 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14071 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: carsten@welcomes-you.com Precedence: bulk X-list: xfs Hi, I have the following scenario: A file server with a 10 TB large xfs file system running on a RAID6 SATA array, the server has 16 GB of memory. I want to test how long it would take to run xfs_repair on it and if the amount of memory is enough for that. Thus I think I would need to: (1) Fill the disk with files (2) Damage the file sytem (3) Run xfs_repair My questions: (1) Is there a nice tool which fills up a disk? I.e. I want to write files with varying size and want to be able to check the validity (md5,sha1...) of the files before and after the damage. I don't know if it matters, but the number of entries per directory should also vary greatly ;) (2) I don't know if xfs_repair cares if the file system was damaged or not. If it uses the same amount of time and memory on a fully intact file system, I guess I don't have a question anymore. Otherwise: How can a damage a xfs file system to make the job harder for xfs_repair. I guess a simple dd if=/dev/random of=/dev/sdb1 with some offsets will not be very effective, right? (3) Anything else I need to be aware of? Thanks for your patience (and yes, I have tried the archives for answers) Cheers Carsten From owner-xfs@oss.sgi.com Wed Jan 2 09:47:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jan 2008 09:47:57 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m02HlnEc030673 for ; Wed, 2 Jan 2008 09:47:52 -0800 X-ASG-Debug-ID: 1199296085-27d8025f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp117.sbc.mail.sp1.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 93B0B1226F2E for ; Wed, 2 Jan 2008 09:48:05 -0800 (PST) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by cuda.sgi.com with SMTP id XU2xxIODbJ2xMKEC for ; Wed, 02 Jan 2008 09:48:05 -0800 (PST) Received: (qmail 47676 invoked from network); 2 Jan 2008 17:48:05 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 2 Jan 2008 17:48:04 -0000 X-YMail-OSG: zmIVVaUVM1mnW9heZzeeaqwl..vMiZ2p.mvrrHn8nZ9UedFT Received: by tuatara.stupidest.org (Postfix, from userid 10000) id C73C4282F2B9; Wed, 2 Jan 2008 09:48:05 -0800 (PST) Date: Wed, 2 Jan 2008 09:48:05 -0800 From: Chris Wedgwood To: Carsten Aulbert Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: How to damage a XFS-Filesystem? Subject: Re: How to damage a XFS-Filesystem? Message-ID: <20080102174805.GA32592@puku.stupidest.org> References: <477B8EAB.8000703@welcomes-you.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <477B8EAB.8000703@welcomes-you.com> X-Barracuda-Connect: smtp117.sbc.mail.sp1.yahoo.com[69.147.64.90] X-Barracuda-Start-Time: 1199296085 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38382 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5342/Wed Jan 2 08:47:10 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14072 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs On Wed, Jan 02, 2008 at 02:16:27PM +0100, Carsten Aulbert wrote: > A file server with a 10 TB large xfs file system running on a RAID6 > SATA array, the server has 16 GB of memory. I want to test how long > it would take to run xfs_repair on it and if the amount of memory is > enough for that. It depends on how fast the IO is and also how many files there are. If you have a small number of really large files it's fairly fast, if you have a large number of really small files (ie. email maildir) then it tends to be much slower. > (2) Damage the file sytem > (3) Run xfs_repair xfs_repair will run without having to damage the filesystem (though if/when damaged it will probably be a little slower). > Otherwise: How can a damage a xfs file system to make the job harder > for xfs_repair. Google for fsfuzzer. > I guess a simple dd if=/dev/random of=/dev/sdb1 with some offsets > will not be very effective, right? If it misses the metadata, xfs_repair won't even notice. If you whack large chunks of metadata you might see considerable data loss. From owner-xfs@oss.sgi.com Wed Jan 2 13:39:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jan 2008 13:39:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m02LdQW9020247 for ; Wed, 2 Jan 2008 13:39:29 -0800 X-ASG-Debug-ID: 1199309973-3a8e00bb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 82E904DA139 for ; Wed, 2 Jan 2008 13:39:34 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id MZJ42rTGcc7wrkSF for ; Wed, 02 Jan 2008 13:39:34 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m02LVeF3005341 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Jan 2008 22:31:40 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m02LVe9i005339 for xfs@oss.sgi.com; Wed, 2 Jan 2008 22:31:40 +0100 Date: Wed, 2 Jan 2008 22:31:40 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] cleanup xfs_vn_mknod Subject: [PATCH] cleanup xfs_vn_mknod Message-ID: <20080102213140.GA5204@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1199309981 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38397 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5343/Wed Jan 2 09:41:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14073 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs - use proper goto based unwinding instead of the current mess of multiple conditionals - rename ip to inode because that's the normal convention for Linux inodes while ip is the convention for xfs_inodes - remove unlikely checks for the default_acl - branches marked unlikely might lead to extreme branch bredictor slowdons if taken and for some workloads a default acl is quite common - properly indent the switch statements - remove xfs_has_fs_struct as nfsd has a fs_struct in any semi-recent kernel Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-21 07:25:06.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-12-21 07:33:25.000000000 +0100 @@ -241,18 +241,6 @@ xfs_init_security( return error; } -/* - * Determine whether a process has a valid fs_struct (kernel daemons - * like knfsd don't have an fs_struct). - * - * XXX(hch): nfsd is broken, better fix it instead. - */ -STATIC_INLINE int -xfs_has_fs_struct(struct task_struct *task) -{ - return (task->fs != init_task.fs); -} - STATIC void xfs_cleanup_inode( struct inode *dir, @@ -284,7 +272,7 @@ xfs_vn_mknod( int mode, dev_t rdev) { - struct inode *ip; + struct inode *inode; bhv_vnode_t *vp = NULL, *dvp = vn_from_inode(dir); xfs_acl_t *default_acl = NULL; attrexists_t test_default_acl = _ACL_DEFAULT_EXISTS; @@ -297,7 +285,7 @@ xfs_vn_mknod( if (unlikely(!sysv_valid_dev(rdev) || MAJOR(rdev) & ~0x1ff)) return -EINVAL; - if (unlikely(test_default_acl && test_default_acl(dvp))) { + if (test_default_acl && test_default_acl(dvp)) { if (!_ACL_ALLOC(default_acl)) { return -ENOMEM; } @@ -307,11 +295,14 @@ xfs_vn_mknod( } } - if (IS_POSIXACL(dir) && !default_acl && xfs_has_fs_struct(current)) + if (IS_POSIXACL(dir) && !default_acl) mode &= ~current->fs->umask; switch (mode & S_IFMT) { - case S_IFCHR: case S_IFBLK: case S_IFIFO: case S_IFSOCK: + case S_IFCHR: + case S_IFBLK: + case S_IFIFO: + case S_IFSOCK: rdev = sysv_encode_dev(rdev); case S_IFREG: error = xfs_create(XFS_I(dir), dentry, mode, rdev, &vp, NULL); @@ -324,32 +315,34 @@ xfs_vn_mknod( break; } - if (unlikely(!error)) { - error = xfs_init_security(vp, dir); - if (error) - xfs_cleanup_inode(dir, vp, dentry, mode); - } + if (unlikely(error)) + goto out_free_acl; - if (unlikely(default_acl)) { - if (!error) { - error = _ACL_INHERIT(vp, mode, default_acl); - if (!error) - xfs_iflags_set(XFS_I(vp), XFS_IMODIFIED); - else - xfs_cleanup_inode(dir, vp, dentry, mode); - } + error = xfs_init_security(vp, dir); + if (unlikely(error)) + goto out_cleanup_inode; + + if (default_acl) { + error = _ACL_INHERIT(vp, mode, default_acl); + if (unlikely(error)) + goto out_cleanup_inode; + xfs_iflags_set(XFS_I(vp), XFS_IMODIFIED); _ACL_FREE(default_acl); } - if (likely(!error)) { - ASSERT(vp); - ip = vn_to_inode(vp); + inode = vn_to_inode(vp); - if (S_ISDIR(mode)) - xfs_validate_fields(ip); - d_instantiate(dentry, ip); - xfs_validate_fields(dir); - } + if (S_ISDIR(mode)) + xfs_validate_fields(inode); + d_instantiate(dentry, inode); + xfs_validate_fields(dir); + return -error; + + out_cleanup_inode: + xfs_cleanup_inode(dir, vp, dentry, mode); + out_free_acl: + if (default_acl) + _ACL_FREE(default_acl); return -error; } From owner-xfs@oss.sgi.com Thu Jan 3 04:49:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jan 2008 04:49:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m03CnhoC016449 for ; Thu, 3 Jan 2008 04:49:48 -0800 X-ASG-Debug-ID: 1199364595-4faf00360000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6CE1D4DD23D for ; Thu, 3 Jan 2008 04:49:55 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 7djmb188imasBatK for ; Thu, 03 Jan 2008 04:49:55 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m03CnnF3005399 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 3 Jan 2008 13:49:49 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m03CnnIh005395 for xfs@oss.sgi.com; Thu, 3 Jan 2008 13:49:49 +0100 Date: Thu, 3 Jan 2008 13:49:49 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] vnode cleanup in xfs_fs_subr.c Subject: [PATCH] vnode cleanup in xfs_fs_subr.c Message-ID: <20080103124949.GA5331@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1199364599 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38459 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5348/Wed Jan 2 21:26:56 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14074 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Cleanup the unneeded intermediate vnode step in the flushing helpers and go directly from the xfs_inode to the struct address_space. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_fs_subr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_fs_subr.c 2007-09-23 14:09:19.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_fs_subr.c 2007-09-23 14:11:55.000000000 +0200 @@ -17,18 +17,7 @@ */ #include "xfs.h" #include "xfs_vnodeops.h" - -/* - * The following six includes are needed so that we can include - * xfs_inode.h. What a mess.. - */ #include "xfs_bmap_btree.h" -#include "xfs_inum.h" -#include "xfs_dir2.h" -#include "xfs_dir2_sf.h" -#include "xfs_attr_sf.h" -#include "xfs_dinode.h" - #include "xfs_inode.h" int fs_noerr(void) { return 0; } @@ -42,11 +31,10 @@ xfs_tosspages( xfs_off_t last, int fiopt) { - bhv_vnode_t *vp = XFS_ITOV(ip); - struct inode *inode = vn_to_inode(vp); + struct address_space *mapping = ip->i_vnode->i_mapping; - if (VN_CACHED(vp)) - truncate_inode_pages(inode->i_mapping, first); + if (mapping->nrpages) + truncate_inode_pages(mapping, first); } int @@ -56,15 +44,14 @@ xfs_flushinval_pages( xfs_off_t last, int fiopt) { - bhv_vnode_t *vp = XFS_ITOV(ip); - struct inode *inode = vn_to_inode(vp); + struct address_space *mapping = ip->i_vnode->i_mapping; int ret = 0; - if (VN_CACHED(vp)) { + if (mapping->nrpages) { xfs_iflags_clear(ip, XFS_ITRUNCATED); - ret = filemap_write_and_wait(inode->i_mapping); + ret = filemap_write_and_wait(mapping); if (!ret) - truncate_inode_pages(inode->i_mapping, first); + truncate_inode_pages(mapping, first); } return ret; } @@ -77,17 +64,16 @@ xfs_flush_pages( uint64_t flags, int fiopt) { - bhv_vnode_t *vp = XFS_ITOV(ip); - struct inode *inode = vn_to_inode(vp); + struct address_space *mapping = ip->i_vnode->i_mapping; int ret = 0; int ret2; - if (VN_DIRTY(vp)) { + if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) { xfs_iflags_clear(ip, XFS_ITRUNCATED); - ret = filemap_fdatawrite(inode->i_mapping); + ret = filemap_fdatawrite(mapping); if (flags & XFS_B_ASYNC) return ret; - ret2 = filemap_fdatawait(inode->i_mapping); + ret2 = filemap_fdatawait(mapping); if (!ret) ret = ret2; } From owner-xfs@oss.sgi.com Thu Jan 3 04:56:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jan 2008 04:56:43 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m03CubX9017257 for ; Thu, 3 Jan 2008 04:56:39 -0800 X-ASG-Debug-ID: 1199365007-725302d20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 498DB11868E5 for ; Thu, 3 Jan 2008 04:56:47 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id WzKwZz168Xb1JLdt for ; Thu, 03 Jan 2008 04:56:47 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m03CufF3005737 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 3 Jan 2008 13:56:41 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m03CufED005735 for xfs@oss.sgi.com; Thu, 3 Jan 2008 13:56:41 +0100 Date: Thu, 3 Jan 2008 13:56:41 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] kill xfs_rwlock/xfs_rwunlock Subject: [PATCH] kill xfs_rwlock/xfs_rwunlock Message-ID: <20080103125641.GC5331@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1199365012 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38458 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5348/Wed Jan 2 21:26:56 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14075 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs We can just use xfs_ilock/xfs_iunlock instead and get rid of the ugly bhv_vrwlock_t. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-26 16:57:48.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-12-26 17:02:32.000000000 +0100 @@ -138,7 +138,7 @@ xfs_dm_send_data_event( xfs_off_t offset, size_t length, int flags, - bhv_vrwlock_t *locktype) + int *lock_flags) { int error; xfs_inode_t *ip; @@ -150,8 +150,8 @@ xfs_dm_send_data_event( ip = xfs_vtoi(vp); do { dmstate = ip->i_d.di_dmstate; - if (locktype) - xfs_rwunlock(ip, *locktype); + if (lock_flags) + xfs_iunlock(ip, *lock_flags); up_rw_sems(inode, flags); @@ -161,8 +161,8 @@ xfs_dm_send_data_event( down_rw_sems(inode, flags); - if (locktype) - xfs_rwlock(ip, *locktype); + if (lock_flags) + xfs_ilock(ip, *lock_flags); } while (!error && (ip->i_d.di_dmstate != dmstate)); return error; @@ -3085,7 +3085,6 @@ xfs_dm_send_mmap_event( xfs_inode_t *ip; int error = 0; dm_eventtype_t max_event = DM_EVENT_READ; - bhv_vrwlock_t locktype; xfs_fsize_t filesize; xfs_off_t length, end_of_area, evsize, offset; int iolock; @@ -3140,20 +3139,16 @@ xfs_dm_send_mmap_event( if (evsize < 0) evsize = 0; - if (max_event == DM_EVENT_READ) { - locktype = VRWLOCK_READ; + if (max_event == DM_EVENT_READ) iolock = XFS_IOLOCK_SHARED; - } - else { - locktype = VRWLOCK_WRITE; + else iolock = XFS_IOLOCK_EXCL; - } xfs_ilock(ip, iolock); /* If write possible, try a DMAPI write event */ if (max_event == DM_EVENT_WRITE && DM_EVENT_ENABLED(ip, max_event)) { error = xfs_dm_send_data_event(max_event, vp, offset, - evsize, 0, &locktype); + evsize, 0, &iolock); goto out_unlock; } @@ -3162,7 +3157,7 @@ xfs_dm_send_mmap_event( */ if (DM_EVENT_ENABLED(ip, DM_EVENT_READ)) { error = xfs_dm_send_data_event(DM_EVENT_READ, vp, offset, - evsize, 0, &locktype); + evsize, 0, &iolock); } out_unlock: xfs_iunlock(ip, iolock); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-12-13 18:56:04.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_aops.c 2007-12-26 17:08:46.000000000 +0100 @@ -1532,9 +1532,9 @@ xfs_vm_bmap( struct xfs_inode *ip = XFS_I(inode); xfs_itrace_entry(XFS_I(inode)); - xfs_rwlock(ip, VRWLOCK_READ); + xfs_ilock(ip, XFS_IOLOCK_SHARED); xfs_flush_pages(ip, (xfs_off_t)0, -1, 0, FI_REMAPF); - xfs_rwunlock(ip, VRWLOCK_READ); + xfs_iunlock(ip, XFS_IOLOCK_SHARED); return generic_block_bmap(mapping, block, xfs_get_blocks); } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-26 16:57:52.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-26 17:01:28.000000000 +0100 @@ -263,8 +263,6 @@ EXPORT_SYMBOL(xfs_mountfs); EXPORT_SYMBOL(xfs_qm_dqcheck); EXPORT_SYMBOL(xfs_readsb); EXPORT_SYMBOL(xfs_read_buf); -EXPORT_SYMBOL(xfs_rwlock); -EXPORT_SYMBOL(xfs_rwunlock); EXPORT_SYMBOL(xfs_setattr); EXPORT_SYMBOL(xfs_attr_get); EXPORT_SYMBOL(xfs_attr_set); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-12-26 16:36:09.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2007-12-26 17:05:08.000000000 +0100 @@ -228,11 +228,11 @@ xfs_read( xfs_ilock(ip, XFS_IOLOCK_SHARED); if (DM_EVENT_ENABLED(ip, DM_EVENT_READ) && !(ioflags & IO_INVIS)) { - bhv_vrwlock_t locktype = VRWLOCK_READ; int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG_RD(ioflags); + int iolock = XFS_IOLOCK_SHARED; ret = -XFS_SEND_DATA(mp, DM_EVENT_READ, vp, *offset, size, - dmflags, &locktype); + dmflags, &iolock); if (ret) { xfs_iunlock(ip, XFS_IOLOCK_SHARED); if (unlikely(ioflags & IO_ISDIRECT)) @@ -287,11 +287,11 @@ xfs_splice_read( xfs_ilock(ip, XFS_IOLOCK_SHARED); if (DM_EVENT_ENABLED(ip, DM_EVENT_READ) && !(ioflags & IO_INVIS)) { - bhv_vrwlock_t locktype = VRWLOCK_READ; + int iolock = XFS_IOLOCK_SHARED; int error; error = XFS_SEND_DATA(mp, DM_EVENT_READ, vp, *ppos, count, - FILP_DELAY_FLAG(infilp), &locktype); + FILP_DELAY_FLAG(infilp), &iolock); if (error) { xfs_iunlock(ip, XFS_IOLOCK_SHARED); return -error; @@ -330,11 +330,11 @@ xfs_splice_write( xfs_ilock(ip, XFS_IOLOCK_EXCL); if (DM_EVENT_ENABLED(ip, DM_EVENT_WRITE) && !(ioflags & IO_INVIS)) { - bhv_vrwlock_t locktype = VRWLOCK_WRITE; + int iolock = XFS_IOLOCK_EXCL; int error; error = XFS_SEND_DATA(mp, DM_EVENT_WRITE, vp, *ppos, count, - FILP_DELAY_FLAG(outfilp), &locktype); + FILP_DELAY_FLAG(outfilp), &iolock); if (error) { xfs_iunlock(ip, XFS_IOLOCK_EXCL); return -error; @@ -580,7 +580,6 @@ xfs_write( xfs_fsize_t isize, new_size; int iolock; int eventsent = 0; - bhv_vrwlock_t locktype; size_t ocount = 0, count; loff_t pos; int need_i_mutex; @@ -607,11 +606,9 @@ xfs_write( relock: if (ioflags & IO_ISDIRECT) { iolock = XFS_IOLOCK_SHARED; - locktype = VRWLOCK_WRITE_DIRECT; need_i_mutex = 0; } else { iolock = XFS_IOLOCK_EXCL; - locktype = VRWLOCK_WRITE; need_i_mutex = 1; mutex_lock(&inode->i_mutex); } @@ -635,8 +632,7 @@ start: xfs_iunlock(xip, XFS_ILOCK_EXCL); error = XFS_SEND_DATA(xip->i_mount, DM_EVENT_WRITE, vp, - pos, count, - dmflags, &locktype); + pos, count, dmflags, &iolock); if (error) { goto out_unlock_internal; } @@ -667,7 +663,6 @@ start: if (!need_i_mutex && (VN_CACHED(vp) || pos > xip->i_size)) { xfs_iunlock(xip, XFS_ILOCK_EXCL|iolock); iolock = XFS_IOLOCK_EXCL; - locktype = VRWLOCK_WRITE; need_i_mutex = 1; mutex_lock(&inode->i_mutex); xfs_ilock(xip, XFS_ILOCK_EXCL|iolock); @@ -744,7 +739,6 @@ retry: mutex_unlock(&inode->i_mutex); iolock = XFS_IOLOCK_SHARED; - locktype = VRWLOCK_WRITE_DIRECT; need_i_mutex = 0; } @@ -781,7 +775,7 @@ retry: if (ret == -ENOSPC && DM_EVENT_ENABLED(xip, DM_EVENT_NOSPACE) && !(ioflags & IO_INVIS)) { - xfs_rwunlock(xip, locktype); + xfs_iunlock(xip, iolock); if (need_i_mutex) mutex_unlock(&inode->i_mutex); error = XFS_SEND_NAMESP(xip->i_mount, DM_EVENT_NOSPACE, vp, @@ -789,7 +783,7 @@ retry: 0, 0, 0); /* Delay flag intentionally unused */ if (need_i_mutex) mutex_lock(&inode->i_mutex); - xfs_rwlock(xip, locktype); + xfs_ilock(xip, iolock); if (error) goto out_unlock_internal; pos = xip->i_size; @@ -817,7 +811,8 @@ retry: /* Handle various SYNC-type writes */ if ((file->f_flags & O_SYNC) || IS_SYNC(inode)) { int error2; - xfs_rwunlock(xip, locktype); + + xfs_iunlock(xip, iolock); if (need_i_mutex) mutex_unlock(&inode->i_mutex); error2 = sync_page_range(inode, mapping, pos, ret); @@ -825,7 +820,7 @@ retry: error = error2; if (need_i_mutex) mutex_lock(&inode->i_mutex); - xfs_rwlock(xip, locktype); + xfs_ilock(xip, iolock); error2 = xfs_write_sync_logforce(mp, xip); if (!error) error = error2; @@ -846,7 +841,7 @@ retry: xip->i_d.di_size = xip->i_size; xfs_iunlock(xip, XFS_ILOCK_EXCL); } - xfs_rwunlock(xip, locktype); + xfs_iunlock(xip, iolock); out_unlock_mutex: if (need_i_mutex) mutex_unlock(&inode->i_mutex); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2007-12-26 17:00:49.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2007-12-26 17:01:28.000000000 +0100 @@ -46,18 +46,6 @@ static inline struct inode *vn_to_inode( } /* - * Values for the vop_rwlock/rwunlock flags parameter. - */ -typedef enum bhv_vrwlock { - VRWLOCK_NONE, - VRWLOCK_READ, - VRWLOCK_WRITE, - VRWLOCK_WRITE_DIRECT, - VRWLOCK_TRY_READ, - VRWLOCK_TRY_WRITE -} bhv_vrwlock_t; - -/* * Return values for xfs_inactive. A return value of * VN_INACTIVE_NOCACHE implies that the file system behavior * has disassociated its state and bhv_desc_t from the vnode. Index: linux-2.6-xfs/fs/xfs/xfs_mount.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.h 2007-12-26 17:00:55.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_mount.h 2007-12-26 17:01:28.000000000 +0100 @@ -67,7 +67,7 @@ struct xfs_mru_cache; */ typedef int (*xfs_send_data_t)(int, bhv_vnode_t *, - xfs_off_t, size_t, int, bhv_vrwlock_t *); + xfs_off_t, size_t, int, int *); typedef int (*xfs_send_mmap_t)(struct vm_area_struct *, uint); typedef int (*xfs_send_destroy_t)(bhv_vnode_t *, dm_right_t); typedef int (*xfs_send_namesp_t)(dm_eventtype_t, struct xfs_mount *, Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-12-26 17:00:49.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-12-26 17:03:55.000000000 +0100 @@ -3398,54 +3398,6 @@ std_return: } int -xfs_rwlock( - xfs_inode_t *ip, - bhv_vrwlock_t locktype) -{ - if (S_ISDIR(ip->i_d.di_mode)) - return 1; - if (locktype == VRWLOCK_WRITE) { - xfs_ilock(ip, XFS_IOLOCK_EXCL); - } else if (locktype == VRWLOCK_TRY_READ) { - return xfs_ilock_nowait(ip, XFS_IOLOCK_SHARED); - } else if (locktype == VRWLOCK_TRY_WRITE) { - return xfs_ilock_nowait(ip, XFS_IOLOCK_EXCL); - } else { - ASSERT((locktype == VRWLOCK_READ) || - (locktype == VRWLOCK_WRITE_DIRECT)); - xfs_ilock(ip, XFS_IOLOCK_SHARED); - } - - return 1; -} - - -void -xfs_rwunlock( - xfs_inode_t *ip, - bhv_vrwlock_t locktype) -{ - if (S_ISDIR(ip->i_d.di_mode)) - return; - if (locktype == VRWLOCK_WRITE) { - /* - * In the write case, we may have added a new entry to - * the reference cache. This might store a pointer to - * an inode to be released in this inode. If it is there, - * clear the pointer and release the inode after unlocking - * this one. - */ - xfs_refcache_iunlock(ip, XFS_IOLOCK_EXCL); - } else { - ASSERT((locktype == VRWLOCK_READ) || - (locktype == VRWLOCK_WRITE_DIRECT)); - xfs_iunlock(ip, XFS_IOLOCK_SHARED); - } - return; -} - - -int xfs_inode_flush( xfs_inode_t *ip, int flags) Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2007-12-26 16:59:57.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2007-12-26 17:03:28.000000000 +0100 @@ -38,8 +38,6 @@ int xfs_readdir(struct xfs_inode *dp, vo int xfs_symlink(struct xfs_inode *dp, bhv_vname_t *dentry, char *target_path, mode_t mode, bhv_vnode_t **vpp, struct cred *credp); -int xfs_rwlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); -void xfs_rwunlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); int xfs_inode_flush(struct xfs_inode *ip, int flags); int xfs_set_dmattrs(struct xfs_inode *ip, u_int evmask, u_int16_t state); int xfs_reclaim(struct xfs_inode *ip); From owner-xfs@oss.sgi.com Thu Jan 3 04:59:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jan 2008 04:59:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m03CxHT2017715 for ; Thu, 3 Jan 2008 04:59:21 -0800 X-ASG-Debug-ID: 1199365171-5d1300780000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9067E1221A17 for ; Thu, 3 Jan 2008 04:59:31 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id hZV0AEKknJxoc9Gq for ; Thu, 03 Jan 2008 04:59:31 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m03CqRF3005494 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 3 Jan 2008 13:52:27 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m03CqRKf005492 for xfs@oss.sgi.com; Thu, 3 Jan 2008 13:52:27 +0100 Date: Thu, 3 Jan 2008 13:52:27 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] kill xfs_get_dir_entry Subject: [PATCH] kill xfs_get_dir_entry Message-ID: <20080103125227.GB5331@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1199365172 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38458 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5348/Wed Jan 2 21:26:56 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14076 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Instead of of xfs_get_dir_entry use a macro to get the xfs_inode from the dentry in the callers and grab the reference manually. Only grab the reference once as it's fine to keep it over the dmapi calls. (And even that reference is actually superflous in Linux but I'll leave that for another patch) Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_rename.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rename.c 2007-11-30 10:15:48.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_rename.c 2007-12-26 16:35:10.000000000 +0100 @@ -94,7 +94,8 @@ xfs_lock_for_rename( xfs_inode_t **i_tab,/* array of inode returned, sorted */ int *num_inodes) /* number of inodes in array */ { - xfs_inode_t *ip1, *ip2, *temp; + xfs_inode_t *ip1 = VNAME_TO_INODE(vname1); + xfs_inode_t *ip2, *temp; xfs_ino_t inum1, inum2; int error; int i, j; @@ -110,16 +111,11 @@ xfs_lock_for_rename( * to see if we still have the right inodes, directories, etc. */ lock_mode = xfs_ilock_map_shared(dp1); - error = xfs_get_dir_entry(vname1, &ip1); - if (error) { - xfs_iunlock_map_shared(dp1, lock_mode); - return error; - } + IHOLD(ip1); + xfs_itrace_ref(ip1); inum1 = ip1->i_ino; - ASSERT(ip1); - xfs_itrace_ref(ip1); /* * Unlock dp1 and lock dp2 if they are different. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2007-12-17 14:49:28.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2007-12-26 16:35:10.000000000 +0100 @@ -230,7 +230,7 @@ static inline bhv_vnode_t *vn_grab(bhv_v */ #define VNAME(dentry) ((char *) (dentry)->d_name.name) #define VNAMELEN(dentry) ((dentry)->d_name.len) -#define VNAME_TO_VNODE(dentry) (vn_from_inode((dentry)->d_inode)) +#define VNAME_TO_INODE(dentry) (XFS_I((dentry)->d_inode)) /* * Dealing with bad inodes Index: linux-2.6-xfs/fs/xfs/xfs_utils.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_utils.c 2007-12-21 07:22:56.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_utils.c 2007-12-26 16:35:10.000000000 +0100 @@ -40,28 +40,6 @@ #include "xfs_itable.h" #include "xfs_utils.h" -/* - * xfs_get_dir_entry is used to get a reference to an inode given - * its parent directory inode and the name of the file. It does - * not lock the child inode, and it unlocks the directory before - * returning. The directory's generation number is returned for - * use by a later call to xfs_lock_dir_and_entry. - */ -int -xfs_get_dir_entry( - bhv_vname_t *dentry, - xfs_inode_t **ipp) -{ - bhv_vnode_t *vp; - - vp = VNAME_TO_VNODE(dentry); - - *ipp = xfs_vtoi(vp); - if (!*ipp) - return XFS_ERROR(ENOENT); - VN_HOLD(vp); - return 0; -} int xfs_dir_lookup_int( Index: linux-2.6-xfs/fs/xfs/xfs_utils.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_utils.h 2007-12-17 14:49:28.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_utils.h 2007-12-26 16:35:10.000000000 +0100 @@ -21,7 +21,6 @@ #define IRELE(ip) VN_RELE(XFS_ITOV(ip)) #define IHOLD(ip) VN_HOLD(XFS_ITOV(ip)) -extern int xfs_get_dir_entry (bhv_vname_t *, xfs_inode_t **); extern int xfs_dir_lookup_int (xfs_inode_t *, uint, bhv_vname_t *, xfs_ino_t *, xfs_inode_t **); extern int xfs_truncate_file (xfs_mount_t *, xfs_inode_t *); Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-12-21 07:45:40.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-12-26 16:35:10.000000000 +0100 @@ -2277,41 +2277,30 @@ xfs_remove( bhv_vnode_t *dir_vp = XFS_ITOV(dp); char *name = VNAME(dentry); xfs_mount_t *mp = dp->i_mount; - xfs_inode_t *ip; + xfs_inode_t *ip = VNAME_TO_INODE(dentry); + int namelen = VNAMELEN(dentry); xfs_trans_t *tp = NULL; int error = 0; xfs_bmap_free_t free_list; xfs_fsblock_t first_block; int cancel_flags; int committed; - int dm_di_mode = 0; int link_zero; uint resblks; - int namelen; xfs_itrace_entry(dp); if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); - namelen = VNAMELEN(dentry); - - if (!xfs_get_dir_entry(dentry, &ip)) { - dm_di_mode = ip->i_d.di_mode; - IRELE(ip); - } - if (DM_EVENT_ENABLED(dp, DM_EVENT_REMOVE)) { error = XFS_SEND_NAMESP(mp, DM_EVENT_REMOVE, dir_vp, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, - name, NULL, dm_di_mode, 0, 0); + name, NULL, ip->i_d.di_mode, 0, 0); if (error) return error; } - /* From this point on, return through std_return */ - ip = NULL; - /* * We need to get a reference to ip before we get our log * reservation. The reason for this is that we cannot call @@ -2324,13 +2313,7 @@ xfs_remove( * when we call xfs_iget. Instead we get an unlocked reference * to the inode before getting our log reservation. */ - error = xfs_get_dir_entry(dentry, &ip); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - goto std_return; - } - - dm_di_mode = ip->i_d.di_mode; + IHOLD(ip); xfs_itrace_entry(ip); xfs_itrace_ref(ip); @@ -2474,7 +2457,7 @@ xfs_remove( (void) XFS_SEND_NAMESP(mp, DM_EVENT_POSTREMOVE, dir_vp, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, - name, NULL, dm_di_mode, error, 0); + name, NULL, ip->i_d.di_mode, error, 0); } return error; @@ -2891,14 +2874,13 @@ xfs_rmdir( char *name = VNAME(dentry); int namelen = VNAMELEN(dentry); xfs_mount_t *mp = dp->i_mount; - xfs_inode_t *cdp; /* child directory */ + xfs_inode_t *cdp = VNAME_TO_INODE(dentry); xfs_trans_t *tp; int error; xfs_bmap_free_t free_list; xfs_fsblock_t first_block; int cancel_flags; int committed; - int dm_di_mode = S_IFDIR; int last_cdp_link; uint resblks; @@ -2907,24 +2889,15 @@ xfs_rmdir( if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); - if (!xfs_get_dir_entry(dentry, &cdp)) { - dm_di_mode = cdp->i_d.di_mode; - IRELE(cdp); - } - if (DM_EVENT_ENABLED(dp, DM_EVENT_REMOVE)) { error = XFS_SEND_NAMESP(mp, DM_EVENT_REMOVE, dir_vp, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, - name, NULL, dm_di_mode, 0, 0); + name, NULL, cdp->i_d.di_mode, 0, 0); if (error) return XFS_ERROR(error); } - /* Return through std_return after this point. */ - - cdp = NULL; - /* * We need to get a reference to cdp before we get our log * reservation. The reason for this is that we cannot call @@ -2937,13 +2910,7 @@ xfs_rmdir( * when we call xfs_iget. Instead we get an unlocked reference * to the inode before getting our log reservation. */ - error = xfs_get_dir_entry(dentry, &cdp); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - goto std_return; - } - mp = dp->i_mount; - dm_di_mode = cdp->i_d.di_mode; + IHOLD(cdp); /* * Get the dquots for the inodes. @@ -3100,7 +3067,7 @@ xfs_rmdir( (void) XFS_SEND_NAMESP(mp, DM_EVENT_POSTREMOVE, dir_vp, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, - name, NULL, dm_di_mode, + name, NULL, cdp->i_d.di_mode, error, 0); } return error; From owner-xfs@oss.sgi.com Thu Jan 3 07:55:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jan 2008 07:55:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_05,HTML_MESSAGE, J_CHICKENPOX_45,J_CHICKENPOX_52,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m03FtdNU032573 for ; Thu, 3 Jan 2008 07:55:41 -0800 X-ASG-Debug-ID: 1199375752-5d13022b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from SVITS26.main.ad.rit.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E849BBE7DA1 for ; Thu, 3 Jan 2008 07:55:52 -0800 (PST) Received: from SVITS26.main.ad.rit.edu (svits26.main.ad.rit.edu [129.21.18.136]) by cuda.sgi.com with ESMTP id dppxY1M4kXM8rR1Z for ; Thu, 03 Jan 2008 07:55:52 -0800 (PST) X-MIMEOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 X-ASG-Orig-Subj: RE: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c Subject: RE: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c Date: Thu, 3 Jan 2008 10:55:48 -0500 Message-ID: <06CCEA2EB1B80A4A937ED59005FA855101C81060@svits26.main.ad.rit.edu> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c Thread-Index: AchDdWO5l6pL6hlRTjGk3QiXs2sgCwKqss9g References: From: "Jay Sullivan" To: Cc: "Jay Sullivan" X-Barracuda-Connect: svits26.main.ad.rit.edu[129.21.18.136] X-Barracuda-Start-Time: 1199375752 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38470 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5348/Wed Jan 2 21:26:56 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 16273 X-archive-position: 14077 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpspgd@rit.edu Precedence: bulk X-list: xfs I'm still seeing a lot of the following in my dmesg. Any ideas? See below for what I have already tried (including moving data to a fresh XFS volume). Tons of these; sometimes the want= changes, but it is always huge. ### attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 ### Occasionally some of these: ### XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4533 of file fs/xfs/xfs_bmap.c. Caller 0xc028c5a2 [] xfs_bmap_read_extents+0x3bd/0x498 [] xfs_iread_extents+0x74/0xe1 [] xfs_iext_realloc_direct+0xa4/0xe7 [] xfs_iex t;c028c5a2>] xfs_iread_extents+0x74/0xe1 [] xfs_bmapi+0x1ca/0x173f [] elv_rb_add+0x6f/0x88 [] as_update_rq+0x32/0x72 [] as_add_request+0x76/0xa4 [] elv_insert+0xd5/0x142 [] __make_request+0xc8/0x305 [] generic_make_request+0x122/0x1d9 [] __map_bio+0x33/0xa9 [] __clone_and_map+0xda/0x34c [] mempool_alloc+0x2a/0xdb [] xfs_ilock+0x58/0xa0 [] xfs_iomap+0x216/0x4b7 [] __xfs_get_blocks+0x6b/0x226 [] radix_tree_node_alloc+0x16/0x57 [] radix_tree_insert+0xb0/0x126 [] xfs_get_blocks+0x28/0x2d [] block_read_full_page+0x192/0x346 [] xfs_get_blocks+0x0/0x2d [] xfs_iget+0x145/0x150 [] do_mpage_readpag 28aba1>] xfs_iunlock+0x43/0x84 [] xfs_vget+0xe1/0xf2 [] find_exported_dentry+0x71/0x4b6 [] __do_page_cache_readahead+0x88/0x153 [] mpage_readpage+0x4b/0x5e [] xfs_get_blocks+0x0/0x2d [] blockable_page_cache_readahead+0x4d/0xb9 [] page_cache_readahead+0x174/0x1a3 [] find_get_page+0x18/0x3a [] do_generic_mapping_read+0x1b5/0x535 [] __capable+0x8/0x1b [] generic_file_sendfile+0x68/0x83 [] nfsd_read_actor+0x0/0x10f [] xfs_sendfile+0x94/0x164 [] nfsd_read_actor+0x0/0x10f [] nfsd_permission+0x6e/0x103 [] xfs_file_sendfile+0x4c/0x5c [] nfsd_read_actor+0x0/0x10f [] nfsd_vfs_read+0x344/0x361 [] nfsd_read_actor+0x0/0x ] nfsd_read+0xd8/0xf9 [] nfsd3_proc_read+0xb0/0x174 [] nfs3svc_decode_readargs+0x0/0xf7 [] nfsd_dispatch+0x8a/0x1f5 [] svcauth_unix_set_client+0x11d/0x175 [] svc_process+0x4fd/0x681 [] nfsd+0x163/0x273 [] nfsd+0x0/0x273 [] kernel_thread_helper+0x7/0x10 ### Thanks! ~Jay From: Jay Sullivan [mailto:jpspgd@rit.edu] Sent: Thursday, December 20, 2007 9:01 PM To: xfs@oss.sgi.com Cc: Jay Sullivan Subject: Re: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c I'm still seeing problems. =( Most recently I have copied all of the data off of the suspect XFS volume onto another fresh XFS volume. A few days later I saw the same messages show up in dmesg. I haven't had a catastrophic failure that makes the kernel remount the FS RO, but I don't want to wait for that to happen. Today I upgraded to the latest stable kernel in Gentoo (2.6.23-r3) and I'm still on xfsprogs 2.9.4, also the latest stable release. A few hours after rebooting to load the new kernel, I saw the following in dmesg: #################### attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in files dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 attempt to access beyond end of device dm-0: rw=0, want=68609558288793608, limit=8178892800 I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0xf3c0079e000000 ("xfs_trans_read_buf") error 5 buf count 4096 ################### These are the same to access a block that is WAAAY outside of the range of my drives) that I was seeing before the last time my FS got remounted read-only by the colonel. Any ideas? What other information can I gather that would help with troubleshooting? Here are some more specifics: This is a Dell PowerEdge 1850 with a FusionMPT/LSI fibre channel card. The XFS volume is a 3.9TB logical volume in LVM. The volume group is spread across LUNs of a Apple XServe RAIDs which are connected o'er FC to our fabric. I just swapped FC switches (to a different brand even) and the problem was showing before and after the switch switch, so that's not it. I have also swapped FC cards, upgraded FC card firmware, updated BIOSs, etc.. This server sees heavy NFS (v3) and samba (currently 3.0.24 until the current regression bug is squashed and stable) traffic. usually sees 200-300Mbps throughput 24/7, although sometimes more. Far-fetched: Is there any way that a particular file on my FS, when accessed, is causing the problem? I have a very similar system (Dell PE 2650, same FC card, same type of RAID, same SFP cables, same GPT scheme, same kernel) but instead with an ext3 (full journal) FS in a 5.[something]TB logical volume (LVM) with no problems. Oh, and it sees system load values in the mid-20s just about all day. Grasping at straws. I need XFS to work because we'll soon be requiring seriously large filesystems with non-sucky extended attribute and ACL support. Plus it's fast and I like it. Can the XFS community help? I don't want to have to turn to that guy that a =P ~Jay On Nov 14, 2007, at 10:05 AM, Jay Sullivan wrote: Of course this had to happen one more time before my scheduled maintenance window... Anyways, here's all of the good stuff I collected. Can anyone make sense of it? Oh, and I upgraded to xfsprogs 2.9.4 last week, so all output you see is with that version. Thanks! ################### dmesg output ################### XFS internal error XFS_WANT_CORRUPTED_GOTO at line 4533 of file fs/xfs/xfs_bmap.c. Caller 0xc028c5a2 [] xfs_bmap_read_extents+0x3bd/0x498 [] xfs_iread_extents+0x74/0xe1 [] xfs_iext_realloc_direct+0xa4/0xe7 [] xfs_iex t;c028c5a2>] xfs_iread_extents+0x74/0xe1 [] xfs_bmapi+0x1ca/0x173f [] elv_rb_add+0x6f/0x88 [] as_update_rq+0x32/0x72 [] as_add_request+0x76/0xa4 [] elv_insert+0xd5/0x142 [] __make_request+0xc8/0x305 [] generic_make_request+0x122/0x1d9 [] __map_bio+0x33/0xa9 [] __clone_and_map+0xda/0x34c [] mempool_alloc+0x2a/0xdb [] xfs_ilock+0x58/0xa0 [] xfs_iomap+0x216/0x4b7 [] __xfs_get_blocks+0x6b/0x226 [] radix_tree_node_alloc+0x16/0x57 [] radix_tree_insert+0xb0/0x126 [] xfs_get_blocks+0x28/0x2d [] block_read_full_page+0x192/0x346 [] xfs_get_blocks+0x0/0x2d [] xfs_iget+0x145/0x150 [] do_mpage_readpag 28aba1>] xfs_iunlock+0x43/0x84 [] xfs_vget+0xe1/0xf2 [] find_exported_dentry+0x71/0x4b6 [] __do_page_cache_readahead+0x88/0x153 [] mpage_readpage+0x4b/0x5e [] xfs_get_blocks+0x0/0x2d [] blockable_page_cache_readahead+0x4d/0xb9 [] page_cache_readahead+0x174/0x1a3 [] find_get_page+0x18/0x3a [] do_generic_mapping_read+0x1b5/0x535 [] __capable+0x8/0x1b [] generic_file_sendfile+0x68/0x83 [] nfsd_read_actor+0x0/0x10f [] xfs_sendfile+0x94/0x164 [] nfsd_read_actor+0x0/0x10f [] nfsd_permission+0x6e/0x103 [] xfs_file_sendfile+0x4c/0x5c [] nfsd_read_actor+0x0/0x10f [] nfsd_vfs_read+0x344/0x361 [] nfsd_read_actor+0x0/0x ] nfsd_read+0xd8/0xf9 [] nfsd3_proc_read+0xb0/0x174 [] nfs3svc_decode_readargs+0x0/0xf7 [] nfsd_dispatch+0x8a/0x1f5 [] svcauth_unix_set_client+0x11d/0x175 [] svc_process+0x4fd/0x681 [] nfsd+0x163/0x273 [] nfsd+0x0/0x273 [] kernel_thread_helper+0x7/0x10 ======================= attempt to access beyond end of device dm-1: rw=0, want=6763361770196172808, limit=7759462400 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x5ddc49b238000000 ("xfs_trans_read_buf") error 5 buf count 4096 xfs_force_shutdown(dm-1,0x1) called from line 415 of file fs/xfs/xfs_trans_buf.c. Return address = 0xc02baa25 Filesystem "dm-1": I/O Error Detected. Shutting down filesystem: dm-1 Please umount the filesystem, and rectify the problem(s) #################### I umount'ed and mount'ed the FS several times, but xfs_repair still told me to use -L... Any ideas? ####################### server-files ~ # umount /mnt/san/ server-files ~ # mount /mnt/san/ server-files ~ # umount /mnt/san/ server-files ~ # xfs_repair /dev/server-files-sanvg01/server-files-sanlv01 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. server-files ~ # xfs_repair -L /dev/server-files-sanvg01/server-files-sanlv01 Pha perblock... 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... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 4002: Badness in key lookup (length) bp=(bno 2561904, len 16384 bytes) key=(bno 2561904, len 8192 bytes) 8003: Badness in key lookup (length) bp=(bno 0, len 512 bytes) key=(bno 0, len 4096 bytes) bad bmap btree ptr 0x5f808b0400000000 in ino 5123809 bad data fork in inode 5123809 cleared inode 5123809 bad magi 480148 (data fork) bmbt block 0 bad data fork in inode 7480148 cleared inode 7480148 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 entry "Fuller_RotoscopeCorrected.mov" at block 0 offset 184 in directory inode 89923 7480148 clearing inode number in entry at offset 184... Phase 5 - rebuild AG headers and trees... - reset superblock... 4000: Badness in key lookup (length) bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes) Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 8992373 (no data entry): rebuilding rebuilding directory inode 8992373 4000: Badness in key lookup (length) bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes) 4000: Badness in key lookup (length) bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes) - traversal finished ... - moving disconnected inodes to lost+found nd correct link counts... 4000: Badness in key lookup (length) bp=(bno 0, len 4096 bytes) key=(bno 0, len 512 bytes) done server-files ~ # mount /mnt/san server-files ~ # umount /mnt/san server-files ~ # xfs_repair -L /dev/server-files-sanvg01/server-files-sanlv01 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... server-files ~ # xfs_repair /dev/server-files-sanvg01/server-files-sanlv01 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... XFS: totally zeroed log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - proc orm inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 Phase 5 - rebuild AG headers and trees... - reset su check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done ################ So that's it for now. Next week I'll be rsyncing all of the data off of this volume to another array. I still want to know what's happening, though... *pout* Anyways, thanks a lot for everyone's help. ~Jay -----Original Message----- From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf Of Jay Sullivan Sent: Friday, November 02, 2007 10:49 AM To: xfs@oss.sgi.com Subject: RE: xf rom file fs/xfs/xfs_trans_buf.c What can I say about Murphy and his silly laws? I just had a drive fail on my array. I wonder if this is the root of my problems... Yay parity. ~Jay -----Original Message----- From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf Of Jay Sullivan Sent: Friday, November 02, 2007 10:00 AM To: xfs@oss.sgi.com Subject: RE: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c I lost the xfs_repair output on an xterm with only four lines of scrollback... I'll definitely be more careful to preserve more 'evidence' next time. =( "Pics or it didn't happen", right? I just upgraded xfsprogs and will scan the disk during my next scheduled downtime (probably in about 2 weeks). I'm tempted to just wipe the volume and start over: I have enough ' to copy everything out to a fresh XFS volume. Regarding "areca": I'm using hardware RAID built into Apple XServe RAIDs o'er LSI FC929X cards. Someone else offered the likely explanation that the btree is corrupted. Isn't this something xfs_repair should be able to fix? Would it be easier, safer, and faster to move the data to a new volume (and restore corrupted files if/as I find them from backup)? We're talking about just less than 4TB of data which used to take about 6 hours to fsck (one pass) with ext3. Restoring the whole shebang from backups would probably take the better part of 12 years (waiting for compression, resetting ACLs, etc.)... FWIW, another (way less important,) much busier and significantly larger logical volume on the same array has been totally fine. Murphy--go figure. Thanks! -----Original Message----- From: Eric Sandeen [mail >] Sent: Thursday, November 01, 2007 10:30 PM To: Jay Sullivan Cc: xfs@oss.sgi.com Subject: Re: xfs_force_shutdown called from file fs/xfs/xfs_trans_buf.c Jay Sullivan wrote: Good eye: it wasn't mountable, thus the -L flag. No recent (unplanned) power outages. The machine and the array that holds the disks are both on serious batteries/UPS and the array's cache batteries are in good health. Did you have the xfs_repair output to see what it found? You might also grab the very latest xfsprogs (2.9.4) in case it's catching more cases. I hate it when people suggest running memtest86, but I might do that anyway. :) What controller are you using? If you say "areca" I might be on to something e seen... -Eric [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Jan 3 10:33:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jan 2008 10:33:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m03IX6dF023297 for ; Thu, 3 Jan 2008 10:33:10 -0800 X-ASG-Debug-ID: 1199385198-346e02610000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CB9844DF7E3 for ; Thu, 3 Jan 2008 10:33:18 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 917VMrUQZw5HNkad for ; Thu, 03 Jan 2008 10:33:18 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m03IXCF3023316 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 3 Jan 2008 19:33:12 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m03IXCe3023314 for xfs@oss.sgi.com; Thu, 3 Jan 2008 19:33:12 +0100 Date: Thu, 3 Jan 2008 19:33:12 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] don't encode parent in nfs filehandles unless nessecary Subject: [PATCH] don't encode parent in nfs filehandles unless nessecary Message-ID: <20080103183311.GA23209@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1199385201 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38481 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5349/Thu Jan 3 07:57:19 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14078 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs As Dave pointed out after the export ops changes we now always encode the parent into the filehandle for regular files, but it's not actually needed when the filesystem is export with no_subtree_check. This one-liner fixes xfs_fs_encode_fh to skip encoding the parent unless nessecary. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_export.c 2008-01-02 17:02:48.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c 2008-01-03 19:30:51.000000000 +0100 @@ -66,7 +66,7 @@ xfs_fs_encode_fh( int len; /* Directories don't need their parent encoded, they have ".." */ - if (S_ISDIR(inode->i_mode)) + if (S_ISDIR(inode->i_mode) || !connectable) fileid_type = FILEID_INO32_GEN; else fileid_type = FILEID_INO32_GEN_PARENT; From owner-xfs@oss.sgi.com Thu Jan 3 21:35:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jan 2008 21:35:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m045ZOIC003862 for ; Thu, 3 Jan 2008 21:35:26 -0800 X-ASG-Debug-ID: 1199424909-1017018a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from py-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 51EFABEF20F for ; Thu, 3 Jan 2008 21:35:09 -0800 (PST) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by cuda.sgi.com with ESMTP id RygloFF33oBID1LP for ; Thu, 03 Jan 2008 21:35:09 -0800 (PST) Received: by py-out-1112.google.com with SMTP id j37so8922208pyc.4 for ; Thu, 03 Jan 2008 21:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=3NCPvD2AXAS+xUHOG6aSdgpNfG1MrkXB2TRkxp4AUyE=; b=W1CI6gUwQ43ZULSv3XF3qAXnkCUfMukePL5qUE52tTzYa8WzN4woskPqHDhL4eIKD8NAY2OroqNN9Wiqk2ZZKjogFgZAcZpCB5UsydHd5VKfOeRB69zkyJqQuuV0vORkXWWCYziSaDomAzrwxuIQwDoKlYqlXcvfXuV7AAL5dKw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=CNc/nNoXk+Z6+59xPZwxQ1Vutnf/916fbk8mbVdD1kBwlaSv4uYMopg9/u6p/VlNH8amgXBqXs/fzc/j7uKSO6qn+9+cbiTDotSoLb1xxJqW76TEspoR7v2/ZR3CHkJZCyVMhVqR/d+FX0MidYb8K3rxl6Gp5azAQ4EE/TqWUis= Received: by 10.143.36.15 with SMTP id o15mr3228970wfj.182.1199424907915; Thu, 03 Jan 2008 21:35:07 -0800 (PST) Received: by 10.142.51.7 with HTTP; Thu, 3 Jan 2008 21:35:07 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 13:35:07 +0800 From: "Changliang Chen" To: "Justin Piszcz" X-ASG-Orig-Subj: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Subject: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org, "Alan Piszcz" In-Reply-To: MIME-Version: 1.0 References: X-Barracuda-Connect: py-out-1112.google.com[64.233.166.176] X-Barracuda-Start-Time: 1199424912 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38525 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5356/Thu Jan 3 21:05:24 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 225 X-archive-position: 14079 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hqucocl@gmail.com Precedence: bulk X-list: xfs Hi Justin=A3=AC From your report=A3=ACIt looks that the p34-default's behavior is better=A3=ACwhich item make you consider that the p34-dchinner looks nice= =A3=BF --=20 Best Regards [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Jan 4 01:08:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jan 2008 01:08:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m04984No028606 for ; Fri, 4 Jan 2008 01:08:07 -0800 X-ASG-Debug-ID: 1199437699-59b200290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1C785BF0B95 for ; Fri, 4 Jan 2008 01:08:19 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id ELPUCxUKQHIDSZPE for ; Fri, 04 Jan 2008 01:08:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D43201C000EE6; Fri, 4 Jan 2008 04:07:48 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5359/Thu Jan 3 21:37:46 2008 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lucidpixels.com Received: from lucidpixels.com ([127.0.0.1]) by localhost (p34.internal.lan [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Lb4O+DSQ-CdT; Fri, 4 Jan 2008 04:07:48 -0500 (EST) Received: by lucidpixels.com (Postfix, from userid 1001) id A5DC21C000EE5; Fri, 4 Jan 2008 04:07:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id A4825409046C; Fri, 4 Jan 2008 04:07:48 -0500 (EST) Date: Fri, 4 Jan 2008 04:07:48 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Changliang Chen cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org, Alan Piszcz X-ASG-Orig-Subj: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. Subject: Re: New XFS benchmarks using David Chinner's recommendations for XFS-based optimizations. In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-260479212-1199437668=:19036" X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1199437700 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38539 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14080 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-260479212-1199437668=:19036 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 4 Jan 2008, Changliang Chen wrote: > Hi Justin=A3=AC From your report=A3=ACIt looks that the p34-default's behavior is better=A3=ACwhich item make you consider that the p34-dchinner looks nice= =A3=BF --=20 Best Regards The re-write and sequential input and output is faster for dchinner. Justin. ---1463747160-260479212-1199437668=:19036-- From owner-xfs@oss.sgi.com Fri Jan 4 07:35:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jan 2008 07:35:47 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=BAYES_50,WHOIS_MYPRIVREG autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m04FZdfB002309 for ; Fri, 4 Jan 2008 07:35:42 -0800 X-ASG-Debug-ID: 1199460951-494a02650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DCEABBF2D9A for ; Fri, 4 Jan 2008 07:35:51 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id CWAiQm1Y48Zfo9w3 for ; Fri, 04 Jan 2008 07:35:51 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JAoZr-0004SN-Il for xfs@oss.sgi.com; Fri, 04 Jan 2008 07:35:19 -0800 Message-ID: <14618811.post@talk.nabble.com> Date: Fri, 4 Jan 2008 07:35:19 -0800 (PST) From: Web Design Company To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Website Design Subject: Re: Website Design In-Reply-To: <000301c5733d$04551010$9400a8c0@XMEN.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: web_design_company@ooyes.net References: <000301c5733d$04551010$9400a8c0@XMEN.local> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1199460954 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38564 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5363/Fri Jan 4 05:37:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14081 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: web_design_company@ooyes.net Precedence: bulk X-list: xfs Hello, nice site Check out site. Officially we are a creative webdesign and outsourcing agency and we do high-quality web solutions. OOYES.NET eagerly helps businesses and individual clients all over the World to establish and maintain a professional Internet presence. http://ooyes.net Web Design Company ----- http://ooyes.net Web design company | http://ooyes.net Graphic design company | http://ooyes.net Outsourcing company -- View this message in context: http://www.nabble.com/Website-Design-tp223981p14618811.html Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Fri Jan 4 14:04:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jan 2008 14:04:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m04M4KZY011011 for ; Fri, 4 Jan 2008 14:04:20 -0800 X-ASG-Debug-ID: 1199484270-02ca01740000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 25522BF95DC for ; Fri, 4 Jan 2008 14:04:30 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id X47CJ8ui2OBOo4kT for ; Fri, 04 Jan 2008 14:04:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D49891C000EF7 for ; Fri, 4 Jan 2008 17:04:29 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5366/Fri Jan 4 12:20:10 2008 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lucidpixels.com Received: from lucidpixels.com ([127.0.0.1]) by localhost (p34.internal.lan [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iL9EkKQm31JJ for ; Fri, 4 Jan 2008 17:04:27 -0500 (EST) Received: by lucidpixels.com (Postfix, from userid 1001) id 87A021C0000A9; Fri, 4 Jan 2008 17:04:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 7CE79408F24E for ; Fri, 4 Jan 2008 17:04:27 -0500 (EST) Date: Fri, 4 Jan 2008 17:04:27 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com X-ASG-Orig-Subj: external log doubles performance? Subject: external log doubles performance? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1199484276 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38588 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14082 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs from a linux-admin page/post: Mon Jul 3 14:22:45 PDT 2006 10 clients started .......................+......+.......+++++....+********* Throughput 182.083 MB/sec (NB=227.604 MB/sec 1820.83 MBit/sec) 10 procs Mon Jul 3 14:22:52 PDT 2006 When the logbufs and logbsize options are added, throughput increases from 92.7404 MB/sec to 96.4556 MB/sec. When the log is moved to an external device the throughput nearly doubles to 182.083 MB/sec. Clearly, the external log increases file system performance under dbench, a program that has a large amount of metadata activity. Tuning the I/O Scheduler -- has anyone done any recent testing? From owner-xfs@oss.sgi.com Sun Jan 6 15:22:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jan 2008 15:22:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m06NMXKG024897 for ; Sun, 6 Jan 2008 15:22:38 -0800 X-ASG-Debug-ID: 1199661767-6aa500580000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B1DFA4ECF23 for ; Sun, 6 Jan 2008 15:22:47 -0800 (PST) Received: from postoffice.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id DOV5lv1aOoOcUCpy for ; Sun, 06 Jan 2008 15:22:47 -0800 (PST) Received: from edge.scott.net.au (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 740EC92CD60; Mon, 7 Jan 2008 10:22:13 +1100 (EST) X-ASG-Orig-Subj: Re: how remove project quota Subject: Re: how remove project quota From: Nathan Scott Reply-To: nscott@aconex.com To: Nelzinho Rocha Cc: xfs@oss.sgi.com In-Reply-To: <3b8ebef50712280418l663cafadm80f884f43dfd3a15@mail.gmail.com> References: <3b8ebef50712280418l663cafadm80f884f43dfd3a15@mail.gmail.com> Content-Type: text/plain Organization: Aconex Date: Mon, 07 Jan 2008 10:24:46 +1100 Message-Id: <1199661886.9463.4.camel@edge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1199661769 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38787 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5390/Sun Jan 6 15:01:04 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14083 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Fri, 2007-12-28 at 10:18 -0200, Nelzinho Rocha wrote: > Hello, > > how remove a project quota? > > Would be sufficient remove project quota the files /etc/projid and > /etc/projects? Or have to do something else? See the xfs_quota man page, in particular the expert-mode "off" and "remove" commands. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jan 6 18:00:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jan 2008 18:01:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0720lTW006272 for ; Sun, 6 Jan 2008 18:00:48 -0800 X-ASG-Debug-ID: 1199671261-053a003a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ug-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DFA76C07706 for ; Sun, 6 Jan 2008 18:01:01 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by cuda.sgi.com with ESMTP id oMqXXgfVoTXTNVCD for ; Sun, 06 Jan 2008 18:01:01 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id o29so3456208ugd.20 for ; Sun, 06 Jan 2008 18:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=WWz7jfXqX1sCdoP0m9ie92TGYflTHrMNXhJZFaWJ9lw=; b=B9eWxxVdakFGJHoaCXVVTUS24ZVUOBaIxSdPsJNLENodeHSsLpWQq7scFIMjcuY/RBqfA5jUcQEqFIrEqV6TsThBqT5y0cUtw+GxXEDx1Hld9dLkNeq0UdhLoUkpu5OWhlb40/hNslZP0sNtUP6GPLwmkngZqYhJiRCMsczNrAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hSEwOdvZbPh6dNlrp25Nkxd/UMqAqi31UGX79zrhYKTb1A57SB3kWPmbESwTVykIQAIidnCNJw2n4Z1XgoGfZkCq0X96oyWyANxfi2O7Q8MgIpI8oh1lnTzhzyEgtB3/wtdgy4QVTR4moIyynO7x688jPGnNpqS7CTgRYjSR8Ko= Received: by 10.67.115.1 with SMTP id s1mr7966888ugm.74.1199671260527; Sun, 06 Jan 2008 18:01:00 -0800 (PST) Received: by 10.66.242.18 with HTTP; Sun, 6 Jan 2008 18:01:00 -0800 (PST) Message-ID: <96c268400801061801i62853e5xdda1b93cc864dda5@mail.gmail.com> Date: Mon, 7 Jan 2008 05:01:00 +0300 From: "Maxim Gordienko" To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair core dump Subject: xfs_repair core dump MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: ug-out-1314.google.com[66.249.92.170] X-Barracuda-Start-Time: 1199671263 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38796 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5395/Sun Jan 6 16:42:23 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14084 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mgordienko@gmail.com Precedence: bulk X-list: xfs Hello! I'm trying to repair damaged xfs partition, but xfs_repair crashes with core dump distribution is fully updated ubuntu 7.10, xfsprogs are 2.9.0. Have tried xfs_repair from other dists like knoppix or gparted livecd, compiled from source last stable (2.9.4-1) same result. Could you please help? Thank you. Phase 5 - rebuild AG headers and trees... *** glibc detected *** xfs_repair: munmap_chunk(): invalid pointer: 0xb514d008 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7ead92b] xfs_repair[0x8062d9a] xfs_repair[0x806c896] xfs_repair[0x8080515] /lib/tls/i686/cmov/libpthread.so.0[0xb7f9846b] /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7f136de] From owner-xfs@oss.sgi.com Sun Jan 6 19:36:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jan 2008 19:37:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m073avsO012555 for ; Sun, 6 Jan 2008 19:36:58 -0800 X-ASG-Debug-ID: 1199677032-501400280000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 95A414ED9AE for ; Sun, 6 Jan 2008 19:37:13 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id Y0dnVMm7uQpxSBTH for ; Sun, 06 Jan 2008 19:37:13 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 58F3E18003F13 for ; Sun, 6 Jan 2008 21:36:40 -0600 (CST) Message-ID: <47819E47.4030906@sandeen.net> Date: Sun, 06 Jan 2008 21:36:39 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: [PATCH] remove CONFIG_XFS_SECURITY Subject: [PATCH] remove CONFIG_XFS_SECURITY Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1199677033 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38803 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5400/Sun Jan 6 18:40:34 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14085 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Is there any point to this option? Sure, it disables the ability to set security attributes at runtime, but it doesn't slim down any code. Any reason to not remove it, and always allow security attributes to be set? Signed-off-by: Eric Sandeen --- Index: linux-2.6.24-rc3/fs/xfs/Kconfig =================================================================== --- linux-2.6.24-rc3.orig/fs/xfs/Kconfig +++ linux-2.6.24-rc3/fs/xfs/Kconfig @@ -35,18 +35,6 @@ config XFS_QUOTA with or without the generic quota support enabled (CONFIG_QUOTA) - they are completely independent subsystems. -config XFS_SECURITY - bool "XFS Security Label support" - depends on XFS_FS - help - Security labels support alternative access control models - implemented by security modules like SELinux. This option - enables an extended attribute namespace for inode security - labels in the XFS filesystem. - - If you are not using a security module that requires using - extended attributes for inode security labels, say N. - config XFS_POSIX_ACL bool "XFS POSIX ACL support" depends on XFS_FS Index: linux-2.6.24-rc3/fs/xfs/linux-2.6/xfs_super.h =================================================================== --- linux-2.6.24-rc3.orig/fs/xfs/linux-2.6/xfs_super.h +++ linux-2.6.24-rc3/fs/xfs/linux-2.6/xfs_super.h @@ -50,13 +50,8 @@ extern void xfs_qm_exit(void); # define set_posix_acl_flag(sb) do { } while (0) #endif -#ifdef CONFIG_XFS_SECURITY -# define XFS_SECURITY_STRING "security attributes, " -# define ENOSECURITY 0 -#else -# define XFS_SECURITY_STRING -# define ENOSECURITY EOPNOTSUPP -#endif +/* Used to be "configurable" so keep it around. */ +#define XFS_SECURITY_STRING "security attributes, " #ifdef CONFIG_XFS_RT # define XFS_REALTIME_STRING "realtime, " Index: linux-2.6.24-rc3/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6.24-rc3.orig/fs/xfs/xfs_attr.c +++ linux-2.6.24-rc3/fs/xfs/xfs_attr.c @@ -2651,7 +2651,7 @@ attr_secure_capable( bhv_vnode_t *vp, cred_t *cred) { - return -ENOSECURITY; + return 0; } STATIC int From owner-xfs@oss.sgi.com Sun Jan 6 20:38:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jan 2008 20:39:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130] (may be forged)) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m074cnem021042 for ; Sun, 6 Jan 2008 20:38:53 -0800 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA26729; Mon, 7 Jan 2008 15:38:35 +1100 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 9B272323C8EA; Mon, 7 Jan 2008 15:38:34 +1100 (EST) To: xfs@oss.sgi.com Cc: sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971186 - dmapi: kill last 2.4 compat leftovers Message-Id: <20080107043834.9B272323C8EA@linuxbuild.melbourne.sgi.com> Date: Mon, 7 Jan 2008 15:38:34 +1100 (EST) X-Virus-Scanned: ClamAV 0.91.2/5400/Sun Jan 6 18:40:34 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14086 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs dmapi: kill last 2.4 compat leftovers Signed-off-by: Christoph Hellwig Date: Mon Jan 7 15:37:20 AEDT 2008 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: linux-melb:dmapi:30299a fs/dmapi/dmapi_sysent.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dmapi/dmapi_sysent.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h - kill last 2.4 compat leftovers fs/dmapi/dmapi_register.c - 1.52 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dmapi/dmapi_register.c.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h - kill last 2.4 compat leftovers From owner-xfs@oss.sgi.com Sun Jan 6 20:41:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jan 2008 20:41:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130] (may be forged)) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m074fUNv021362 for ; Sun, 6 Jan 2008 20:41:34 -0800 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA26818; Mon, 7 Jan 2008 15:41:15 +1100 Message-ID: <4781AD6A.2000007@sgi.com> Date: Mon, 07 Jan 2008 15:41:14 +1100 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] dmapi: kill last 2.4 compat leftovers References: <20071130093909.GB2949@lst.de> <20071221063703.GA23706@lst.de> In-Reply-To: <20071221063703.GA23706@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5400/Sun Jan 6 18:40:34 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14087 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > Any reason this didn't get in yet? No its in now, thanks for the reminder. Don > On Fri, Nov 30, 2007 at 10:39:09AM +0100, Christoph Hellwig wrote: >> Signed-off-by: Christoph Hellwig >> >> Index: linux-2.6-xfs/fs/dmapi/dmapi_register.c >> =================================================================== >> --- linux-2.6-xfs.orig/fs/dmapi/dmapi_register.c 2007-09-29 11:49:22.000000000 +0200 >> +++ linux-2.6-xfs/fs/dmapi/dmapi_register.c 2007-09-29 11:49:39.000000000 +0200 From owner-xfs@oss.sgi.com Sun Jan 6 23:11:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jan 2008 23:12:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m077BsrV022745 for ; Sun, 6 Jan 2008 23:11:56 -0800 X-ASG-Debug-ID: 1199689930-061c003b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 20F12C08B36 for ; Sun, 6 Jan 2008 23:12:10 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id S7ASs8H6stBjDQoN for ; Sun, 06 Jan 2008 23:12:10 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JBm9Z-0007kb-5e; Mon, 07 Jan 2008 07:12:09 +0000 Date: Mon, 7 Jan 2008 07:12:09 +0000 From: Christoph Hellwig To: Eric Sandeen Cc: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] remove CONFIG_XFS_SECURITY Subject: Re: [PATCH] remove CONFIG_XFS_SECURITY Message-ID: <20080107071208.GA29713@infradead.org> References: <47819E47.4030906@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47819E47.4030906@sandeen.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1199689931 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38818 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5403/Sun Jan 6 20:30:32 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14088 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Sun, Jan 06, 2008 at 09:36:39PM -0600, Eric Sandeen wrote: > Is there any point to this option? Sure, it disables the ability > to set security attributes at runtime, but it doesn't slim down > any code. > > Any reason to not remove it, and always allow security attributes > to be set? I suspect the reason it is there currently is because the other filesystems have similar option. Removing it sounds perfectly fine to me. From owner-xfs@oss.sgi.com Mon Jan 7 12:27:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jan 2008 12:27:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m07KRjlO029509 for ; Mon, 7 Jan 2008 12:27:47 -0800 X-ASG-Debug-ID: 1199737681-292602d80000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A1CAB4F1CB5 for ; Mon, 7 Jan 2008 12:28:01 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by cuda.sgi.com with ESMTP id kGitqY8lvbGDZehx for ; Mon, 07 Jan 2008 12:28:01 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so13565651waf.18 for ; Mon, 07 Jan 2008 12:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=HqPw7n4PdRLEWPEhtDSckYorIq1ww9tLAmYR/xbqRdY=; b=dZ7Df1jz2JjDUg7vDGYSvjlvu9tqgBmmJoWX3YABZklOWq+LkWGh1F0YoNiMP3dmfa3ZttZT5nnTtVCk1ZaWU02OzrgJ0lox9tSRHQt5C/1sm3psLALjgOdDDOpnwxz2CeZGt2gA6o/KyrW5S/f4kOHxDVx/Z4l7fZFW/O8G0tc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Kco3wGpagmkJl6+mllHki7+536GM2u0sgoDrfZH0BQpIRabkFVI8+aqptU+UYH7SEgRqC7holJ/YnWaeZJklvCAsgLN/x0XgpdMF25c1W7tbASo3KlLAMr/cnqCeMcPFEYgkWl0VgUdIVyG+nE5T1o8cQRvMqA4KB3+XijK57Is= Received: by 10.114.190.6 with SMTP id n6mr22739325waf.51.1199737679967; Mon, 07 Jan 2008 12:27:59 -0800 (PST) Received: by 10.114.255.19 with HTTP; Mon, 7 Jan 2008 12:27:59 -0800 (PST) Message-ID: <5d96567b0801071227i509402ccuce044106cc8959af@mail.gmail.com> Date: Mon, 7 Jan 2008 22:27:59 +0200 From: Raz To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: mount option swalloc Subject: mount option swalloc MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.181] X-Barracuda-Start-Time: 1199737681 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38870 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5420/Mon Jan 7 06:34:42 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14089 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Does it work ? I have created several 100MBytes files over raid5 and they don't seem to be starting at modulo (swidth ) = 0. conf: sunit=1M , raid5 with 4 sata disks. swidth=3MB. meta-data=/dev/md1 isize=256 agcount=32, agsize=5687296 blks = sectsz=4096 attr=0 data = bsize=4096 blocks=181989888, imaxpct=25 = sunit=256 swidth=768 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks realtime =none extsz=3145728 blocks=0, rtextents=0 I am using 2.6.17 vanilla kernel . thank you -- Raz From owner-xfs@oss.sgi.com Mon Jan 7 14:53:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jan 2008 14:53:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m07MrnAB010479 for ; Mon, 7 Jan 2008 14:53:52 -0800 X-ASG-Debug-ID: 1199746444-16fe00550000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 091D14F29E2 for ; Mon, 7 Jan 2008 14:54:05 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id bwrRLTP9HuGcd2fo for ; Mon, 07 Jan 2008 14:54:05 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m07MrvF3024427 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 7 Jan 2008 23:53:57 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m07MrvMT024425 for xfs@oss.sgi.com; Mon, 7 Jan 2008 23:53:57 +0100 Date: Mon, 7 Jan 2008 23:53:57 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: fix unaligned access in readdir Subject: Re: [PATCH] xfs: fix unaligned access in readdir Message-ID: <20080107225357.GA24361@lst.de> References: <20071226154857.GA3472@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071226154857.GA3472@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1199746446 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38880 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5421/Mon Jan 7 12:23:36 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14090 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Wed, Dec 26, 2007 at 04:48:57PM +0100, Christoph Hellwig wrote: > This patch should fix the issue seen on Alpha with unaligned accesses > in the new readdir code. By aligning each dirent to sizeof(u64) we'll > avoid unaligned accesses. To make doubly sure we're not hitting > problems also rearrange struct hack_dirent to avoid holes. If anyone in Melbourne is getting back from Holidays it would be nice if we could get this patch into 2.6.24-final still.. From owner-xfs@oss.sgi.com Mon Jan 7 20:34:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jan 2008 20:34:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m084YPqb012563 for ; Mon, 7 Jan 2008 20:34:29 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA05295; Tue, 8 Jan 2008 15:34:36 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 8676858C4C0F; Tue, 8 Jan 2008 15:34:36 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 975411 - fix unaligned access in readdir Message-Id: <20080108043436.8676858C4C0F@chook.melbourne.sgi.com> Date: Tue, 8 Jan 2008 15:34:36 +1100 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/5428/Mon Jan 7 18:45:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14091 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs fix unaligned access in readdir This patch should fix the issue seen on Alpha with unaligned accesses in the new readdir code. By aligning each dirent to sizeof(u64) we'll avoid unaligned accesses. To make doubly sure we're not hitting problems also rearrange struct hack_dirent to avoid holes. Signed-off-by: Christoph Hellwig Date: Tue Jan 8 15:33:20 AEDT 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-readdir Inspected by: Christoph Hellwig Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30302a fs/xfs/linux-2.6/xfs_file.c - 1.162 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.162&r2=text&tr2=1.161&f=h - fix unaligned access in readdir From owner-xfs@oss.sgi.com Mon Jan 7 20:41:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jan 2008 20:41:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m084exIf013249 for ; Mon, 7 Jan 2008 20:41:01 -0800 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA05452; Tue, 8 Jan 2008 15:41:12 +1100 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id B6C9B323B2C0; Tue, 8 Jan 2008 15:41:11 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 970982 - Remove empty, duplicate, kdb headers. Message-Id: <20080108044111.B6C9B323B2C0@linuxbuild.melbourne.sgi.com> Date: Tue, 8 Jan 2008 15:41:11 +1100 (EST) X-Virus-Scanned: ClamAV 0.91.2/5428/Mon Jan 7 18:45:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14092 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Date: Tue Jan 8 15:36:56 AEDT 2008 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:30304a include/kdbprivate.h - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/kdbprivate.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/kdb.h - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/kdb.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - Remove empty, duplicate, kdb headers. From owner-xfs@oss.sgi.com Tue Jan 8 01:32:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jan 2008 01:33:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m089Wlss011999 for ; Tue, 8 Jan 2008 01:32:50 -0800 X-ASG-Debug-ID: 1199784782-1ebd018f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ug-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A9A6CC25D2E for ; Tue, 8 Jan 2008 01:33:03 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by cuda.sgi.com with ESMTP id Fcb660kOoiwZsDO5 for ; Tue, 08 Jan 2008 01:33:03 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id o29so3671041ugd.20 for ; Tue, 08 Jan 2008 01:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BU3YZy6H4gaLwxeXbymbvlfzJYYdBbucTJClcT/PkoQ=; b=b35yHJlkno14S+CrI23/OPHtd2Q8gklJYHw04IoGD20AsriUtm0aCk/XhYwbETQjxs3J5ALmfOtD1xW2kG9yC3j+b0/X/RWN6abpL1ESvrNfLtks7HuLqNabk/zy497TCJAAnX8jAbp8tGBqZPD58wsWTjNP7CyWLUKdPQEp/UQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=yDQwCDIRsVA28g8szLKXv+PIsREwKKzBtkbtsn2BdEaEvn4OvkNAIr5p5w4LBjqyJ8rqzgNLoeJ/eSCkuju0OJPqmsBln0ggPFfG0uWn7hW3VgXdUa2b4rnwXgW6+TSPK4sF4yGn+vTlDywkuWFNAE5PpK625IvV+TrPoPSV6Uk= Received: by 10.66.252.18 with SMTP id z18mr805091ugh.37.1199783107654; Tue, 08 Jan 2008 01:05:07 -0800 (PST) Received: by 10.66.242.18 with HTTP; Tue, 8 Jan 2008 01:05:07 -0800 (PST) Message-ID: <96c268400801080105h68a75233ia82e05d8debaabe6@mail.gmail.com> Date: Tue, 8 Jan 2008 12:05:07 +0300 From: "Maxim Gordienko" To: "Barry Naujok" X-ASG-Orig-Subj: Re: xfs_repair core dump Subject: Re: xfs_repair core dump Cc: xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <96c268400801061801i62853e5xdda1b93cc864dda5@mail.gmail.com> X-Barracuda-Connect: ug-out-1314.google.com[66.249.92.174] X-Barracuda-Start-Time: 1199784783 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38921 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5429/Tue Jan 8 01:00:19 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14093 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mgordienko@gmail.com Precedence: bulk X-list: xfs On Jan 8, 2008 7:21 AM, Barry Naujok wrote: > On Mon, 07 Jan 2008 13:01:00 +1100, Maxim Gordienko > wrote: > > > Hello! > > > > I'm trying to repair damaged xfs partition, but xfs_repair crashes > > with core dump > > distribution is fully updated ubuntu 7.10, xfsprogs are 2.9.0. > > Have tried xfs_repair from other dists like knoppix or gparted livecd, > > compiled from source last stable (2.9.4-1) > > same result. Could you please help? Thank you. > > Would it be possible to obtain an image or metadump image of your > filesystem so I can diagnose the xfs_repair problem here? > > xfs_metadump obfuscates most filenames if privacy is an issue. > I shared metadump at https://mastubuntu.dyndns.org/xfs.dump.bz2 sorry, partition is 175gb big, i cannot create full dump. > Regards, > Barry. > > > > Phase 5 - rebuild AG headers and trees... > > *** glibc detected *** xfs_repair: munmap_chunk(): invalid pointer: > > 0xb514d008 *** > > ======= Backtrace: ========= > > /lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7ead92b] > > xfs_repair[0x8062d9a] > > xfs_repair[0x806c896] > > xfs_repair[0x8080515] > > /lib/tls/i686/cmov/libpthread.so.0[0xb7f9846b] > > /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7f136de] > > > > > > > From owner-xfs@oss.sgi.com Tue Jan 8 02:50:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jan 2008 02:50:08 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m08Ao0I7017793 for ; Tue, 8 Jan 2008 02:50:03 -0800 X-ASG-Debug-ID: 1199789416-1ebd022f0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5FCE911A05EF for ; Tue, 8 Jan 2008 02:50:17 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id QhxOgjn036HylD8N for ; Tue, 08 Jan 2008 02:50:17 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 695001C00023F; Tue, 8 Jan 2008 05:50:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 5B0A74019348; Tue, 8 Jan 2008 05:50:16 -0500 (EST) Date: Tue, 8 Jan 2008 05:50:16 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Raz cc: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount option swalloc Subject: Re: mount option swalloc In-Reply-To: <5d96567b0801071227i509402ccuce044106cc8959af@mail.gmail.com> Message-ID: References: <5d96567b0801071227i509402ccuce044106cc8959af@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1199789417 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38927 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5429/Tue Jan 8 01:00:19 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14094 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Isn't 2.6.17 - 2.6.17.6 the bugged version of the kernel that corrupts XFS filesystems? I suggest you run a different kernel version and xfs_repair on your XFS filesystems. Justin. On Mon, 7 Jan 2008, Raz wrote: > Does it work ? > I have created several 100MBytes files over raid5 and they don't seem > to be starting at modulo (swidth ) = 0. > conf: sunit=1M , raid5 with 4 sata disks. swidth=3MB. > > meta-data=/dev/md1 isize=256 agcount=32, agsize=5687296 blks > = sectsz=4096 attr=0 > data = bsize=4096 blocks=181989888, imaxpct=25 > = sunit=256 swidth=768 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=2 > = sectsz=4096 sunit=1 blks > realtime =none extsz=3145728 blocks=0, rtextents=0 > > I am using 2.6.17 vanilla kernel . > > thank you > -- > Raz > > From owner-xfs@oss.sgi.com Tue Jan 8 06:07:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jan 2008 06:07:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40,UNPARSEABLE_RELAY autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m08E6v4M006674 for ; Tue, 8 Jan 2008 06:07:00 -0800 X-ASG-Debug-ID: 1199801230-3dc300350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out5.blueyonder.co.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4D829C25FA2 for ; Tue, 8 Jan 2008 06:07:10 -0800 (PST) Received: from smtp-out5.blueyonder.co.uk (smtp-out5.blueyonder.co.uk [195.188.213.8]) by cuda.sgi.com with ESMTP id 4ScVJI4l1BrngISM for ; Tue, 08 Jan 2008 06:07:10 -0800 (PST) Received: from [172.23.170.139] (helo=anti-virus01-10) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1JCEx0-0002W0-Vl for xfs@oss.sgi.com; Tue, 08 Jan 2008 13:57:07 +0000 Received: from [195.188.53.233] (helo=webmail.blueyonder.co.uk) by asmtp-out3.blueyonder.co.uk with esmtp (Exim 4.52) id 1JCEx0-0001h6-Il for xfs@oss.sgi.com; Tue, 08 Jan 2008 13:57:06 +0000 Received: from 82.45.191.179 (SquirrelMail authenticated user); by webmail.blueyonder.co.uk with HTTP; Tue, 8 Jan 2008 13:57:06 -0000 (GMT) Message-ID: <59227.82.45.191.179.1199800626.SVkUQ21ZSE16Sg==.squirrel@82.45.191.179> Date: Tue, 8 Jan 2008 13:57:06 -0000 (GMT) X-ASG-Orig-Subj: xfs creation options - raid Subject: xfs creation options - raid From: carpcatcher@blueyonder.co.uk To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: smtp-out5.blueyonder.co.uk[195.188.213.8] X-Barracuda-Start-Time: 1199801234 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.47 X-Barracuda-Spam-Status: No, SCORE=-1.47 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=NO_REAL_NAME, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.38941 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Virus-Scanned: ClamAV 0.91.2/5432/Tue Jan 8 04:57:41 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14095 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: carpcatcher@blueyonder.co.uk Precedence: bulk X-list: xfs Hello, been reading documents but still not sure what are best option to use when creating xfs on my raid system. Raid card details below. I have 2 raid 1 arrays which will have xfs partitions: Array 1 55gb with 1 40gb xfs partition for /home Array set as stripe 64kb block 512 bytes Array 2 645gb 1 xfs partition using all space for file storage Array set as stripe 128kb block 512 bytes I have been looking at docs and come with following to create FS on 645gb xfs partition. mkfs.xfs -f -d agcount=42 -l size=64m /dev/sde5 The default agcount= was 32 but am not 100% sure how to work this out for correct number? I would mount with following options: mount -o logbufs=8,noatime,nodiratime The other setting am not sure how to get right is this bit from docs: "XFS allows you to select the stripe unit for a RAID device or stripe volume." Now i know i need to set -d su= -d sw= but best to work this out for my arrays? The 645gb array/partition will be used for files 3mb to 250mb with most being about 20/30mb Raid is Areca 1210 raid controller: Adapter Architecture ARC-1210 uses IntelR IOP332 I/O processor. ARC-1220/1230/1260 uses IntelR IOP333 I/O processor PCI-Express X8 bus 256MB on-board DDR333 SDRAM with ECC protection(4/8-port) One SODIMM socket with default 256MB of DDR333 SDRAM with ECC protection, Upgrade to 1GB. An ECC or non-ECC SDRAM module using X8 or X16 chip organization (12/16/24-port) Write-through or write-back cache From owner-xfs@oss.sgi.com Wed Jan 9 15:00:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jan 2008 15:00:10 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m09N02gR023263 for ; Wed, 9 Jan 2008 15:00:04 -0800 X-ASG-Debug-ID: 1199919618-7a7c01050000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B99AC50135F for ; Wed, 9 Jan 2008 15:00:18 -0800 (PST) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id CYYQYjNbJl0bYtmF for ; Wed, 09 Jan 2008 15:00:18 -0800 (PST) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m09MxsWb016314 for ; Wed, 9 Jan 2008 14:59:54 -0800 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m09MxnJ1016417 for ; Wed, 9 Jan 2008 14:59:49 -0800 Received: from [10.123.4.142] ([10.123.4.142]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jan 2008 15:00:12 -0800 Message-ID: <478551FC.3040909@agami.com> Date: Wed, 09 Jan 2008 15:00:12 -0800 From: Michael Nishimoto User-Agent: Mail/News 1.5.0.4 (X11/20060629) MIME-Version: 1.0 To: XFS Mailing List X-ASG-Orig-Subj: CVS access down? Subject: CVS access down? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jan 2008 23:00:12.0373 (UTC) FILETIME=[63CA1050:01C85313] X-Scanned-By: MIMEDefang 2.58 on 192.168.168.13 X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1199919619 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0094 1.0000 -1.9599 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.96 X-Barracuda-Spam-Status: No, SCORE=-1.96 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39072 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5459/Wed Jan 9 08:00:29 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14096 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miken@agami.com Precedence: bulk X-list: xfs It appears that CVS access is down. Can someone please take a look to see what's broken? Thanks! From owner-xfs@oss.sgi.com Wed Jan 9 20:55:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jan 2008 20:56:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0A4tpjw001576 for ; Wed, 9 Jan 2008 20:55:55 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA21513; Thu, 10 Jan 2008 15:56:03 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id A61C458C4C0F; Thu, 10 Jan 2008 15:56:03 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 974151 - prevent panic during log recovery due to bogus operation header length Message-Id: <20080110045603.A61C458C4C0F@chook.melbourne.sgi.com> Date: Thu, 10 Jan 2008 15:56:03 +1100 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/5462/Wed Jan 9 18:48:40 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14097 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs prevent panic during log recovery due to bogus operation header length A problem was reported where a system panicked in log recovery due to a corrupt log record. The cause of the corruption is not known but this change will at least prevent a crash for this specific scenario. Log recovery definitely needs some more work in this area. Date: Thu Jan 10 15:54:49 AEDT 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-free Inspected by: dgc hch@infradead.org Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30318a fs/xfs/xfs_log_recover.c - 1.333 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.333&r2=text&tr2=1.332&f=h - prevent panic during log recovery due to bogus operation header length From owner-xfs@oss.sgi.com Wed Jan 9 23:19:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jan 2008 23:20:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0A7JmGx018064 for ; Wed, 9 Jan 2008 23:19:49 -0800 X-ASG-Debug-ID: 1199949601-3e2b00380000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ug-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 16DD6502CEF for ; Wed, 9 Jan 2008 23:20:02 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by cuda.sgi.com with ESMTP id s81zRQvzVH4ifvcH for ; Wed, 09 Jan 2008 23:20:02 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id o29so209182ugd.20 for ; Wed, 09 Jan 2008 23:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=AOK4e24SIFatYIQzCF3BPNeOzFynzxB8Dba630YXjFI=; b=b7qix53xvNwELvCj6qfaECYkEbJpEbcQPasSNrq6sRTBegfyPsp0XYtT2lP9Td5JdZqqXe+2fsq8gSeBCBsAxE/cJoX+dVjD9COKVU1kC/t1yZ+g47KipV25HnkMqM5RbXqfi5nfeehzDWiS2OsJfi2dHNmXSYblG4444IZEA0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ruqlJSOLj/7N5RsyClllIkOU8CVK8Owq8ReFDShMQDM5vwPWkdFddo2kIhcjAZNg9wzEXFa8Av9MG+5iQaMZntRhuC1RZEol4Dl5vMXaQmQAvi7Vhnp41yJMsHOGP6MY9mzTDB/X2aaaGJqB6l3V9ffr0QAUoCCYMEas1znjwBE= Received: by 10.67.116.11 with SMTP id t11mr3189584ugm.61.1199949600972; Wed, 09 Jan 2008 23:20:00 -0800 (PST) Received: by 10.66.242.18 with HTTP; Wed, 9 Jan 2008 23:20:00 -0800 (PST) Message-ID: <96c268400801092320i70a4f0d4i70050aad4b6125b2@mail.gmail.com> Date: Thu, 10 Jan 2008 10:20:00 +0300 From: "Maxim Gordienko" To: "Barry Naujok" X-ASG-Orig-Subj: Re: xfs_repair core dump Subject: Re: xfs_repair core dump Cc: xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <96c268400801061801i62853e5xdda1b93cc864dda5@mail.gmail.com> <96c268400801080105h68a75233ia82e05d8debaabe6@mail.gmail.com> X-Barracuda-Connect: ug-out-1314.google.com[66.249.92.172] X-Barracuda-Start-Time: 1199949605 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39106 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5464/Wed Jan 9 19:16:47 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14098 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mgordienko@gmail.com Precedence: bulk X-list: xfs On Jan 10, 2008 6:58 AM, Barry Naujok wrote: > On Tue, 08 Jan 2008 20:05:07 +1100, Maxim Gordienko > wrote: > > > On Jan 8, 2008 7:21 AM, Barry Naujok wrote: > >> On Mon, 07 Jan 2008 13:01:00 +1100, Maxim Gordienko > >> > >> wrote: > >> > >> > Hello! > >> > > >> > I'm trying to repair damaged xfs partition, but xfs_repair crashes > >> > with core dump > >> > distribution is fully updated ubuntu 7.10, xfsprogs are 2.9.0. > >> > Have tried xfs_repair from other dists like knoppix or gparted livecd, > >> > compiled from source last stable (2.9.4-1) > >> > same result. Could you please help? Thank you. > > Ok, I think I have it! > > Can you try the attached patch to 2.9.4 source. It should "repair" your > disk. There are a lot of inodes that have problems and quite a few > will end up in lost+found. > > Regards, > Barry. Thank you Barry! works like a charm! about 5k files end up in lost+found, long way to recover them. Hope to see this patch in next release of xfsprogs (actually, hope never use xfs_repair again) Thank you again! From owner-xfs@oss.sgi.com Thu Jan 10 18:29:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jan 2008 18:29:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0B2TTp0020326 for ; Thu, 10 Jan 2008 18:29:30 -0800 X-ASG-Debug-ID: 1200018583-4ca1003f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from slurp.thebarn.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 94E6E50A24C for ; Thu, 10 Jan 2008 18:29:43 -0800 (PST) Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by cuda.sgi.com with ESMTP id fw4JyMqW9d0EmVps for ; Thu, 10 Jan 2008 18:29:43 -0800 (PST) Received: from [127.0.0.1] (slurp.thebarn.com [208.42.117.201]) (authenticated bits=0) by slurp.thebarn.com (8.14.0/8.13.8) with ESMTP id m0B2ONEs038961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2008 20:24:27 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <4786D35C.9030104@thebarn.com> Date: Thu, 10 Jan 2008 20:24:28 -0600 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.9 (X11/20071227) MIME-Version: 1.0 To: Michael Nishimoto CC: XFS Mailing List X-ASG-Orig-Subj: Re: CVS access down? Subject: Re: CVS access down? References: <478551FC.3040909@agami.com> In-Reply-To: <478551FC.3040909@agami.com> Content-Type: multipart/mixed; boundary="------------080102060705030408080809" X-Virus-Scanned: ClamAV 0.91.2/5473/Thu Jan 10 15:56:40 2008 on oss.sgi.com X-Virus-Scanned: ClamAV 0.91.2/5473/Thu Jan 10 17:56:40 2008 on slurp.thebarn.com X-Virus-Status: Clean X-Barracuda-Connect: cattelan-host202.dsl.visi.com[208.42.117.202] X-Barracuda-Start-Time: 1200018586 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39182 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 14099 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------080102060705030408080809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael Nishimoto wrote: > It appears that CVS access is down. Can someone please take > a look to see what's broken? > > Thanks! > Anymore info? I just did quick test cvs -d :pserver:cvs@oss.sgi.com:/cvs co xfs-cmds seems to be working fine for me. -Russell --------------080102060705030408080809 Content-Type: text/x-vcard; charset=utf-8; name="cattelan.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cattelan.vcf" begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard --------------080102060705030408080809-- From owner-xfs@oss.sgi.com Thu Jan 10 23:07:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jan 2008 23:07:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0B77RKO026384 for ; Thu, 10 Jan 2008 23:07:31 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA29899; Fri, 11 Jan 2008 18:07:37 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 115D758C4C0F; Fri, 11 Jan 2008 18:07:36 +1100 (EST) Date: Fri, 11 Jan 2008 18:07:36 +1100 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.24-rc8 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20080111070737.115D758C4C0F@chook.melbourne.sgi.com> From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/5473/Thu Jan 10 15:56:40 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14100 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_file.c | 16 ++++++++++------ 1 files changed, 10 insertions(+), 6 deletions(-) through these commits: commit aea6ad0ce5e215ce99fe9e3edd9268f696862d8f Author: Christoph Hellwig Date: Thu Jan 10 16:43:26 2008 +1100 [XFS] fix unaligned access in readdir This patch should fix the issue seen on Alpha with unaligned accesses in the new readdir code. By aligning each dirent to sizeof(u64) we'll avoid unaligned accesses. To make doubly sure we're not hitting problems also rearrange struct hack_dirent to avoid holes. SGI-PV: 975411 SGI-Modid: xfs-linux-melb:xfs-kern:30302a Signed-off-by: Christoph Hellwig Signed-off-by: Lachlan McIlroy From owner-xfs@oss.sgi.com Fri Jan 11 09:07:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Jan 2008 09:08:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,BigEvilList_RX, URI_HEX autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0BH7oTH003414 for ; Fri, 11 Jan 2008 09:07:52 -0800 X-ASG-Debug-ID: 1200071284-4063031c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bounce.jcnet.ad.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4C7E711B8E8C for ; Fri, 11 Jan 2008 09:08:05 -0800 (PST) Received: from bounce.jcnet.ad.jp (bounce.jcnet.ad.jp [218.219.80.234]) by cuda.sgi.com with ESMTP id 4QSrOks9t3PAmZHK for ; Fri, 11 Jan 2008 09:08:05 -0800 (PST) Received: from smtp.jcnet.ad.jp (localhost [127.0.0.1]) by bounce.jcnet.ad.jp (Postfix) with ESMTP id 443CA2E6CF7 for ; Sat, 12 Jan 2008 02:08:03 +0900 (JST) Received: from mg01vsv.sv.jcnet.ad.jp (mailservers [10.1.0.99]) by smtp.jcnet.ad.jp (Postfix) with ESMTP id 3912BC3CC8 for ; Sat, 12 Jan 2008 02:08:03 +0900 (JST) Received: from localhost (localhost) by mg01vsv.sv.jcnet.ad.jp (MOS 3.7.3a-GA) with internal id CVQ00834; Sat, 12 Jan 2008 02:07:51 +0900 (JST) Date: Sat, 12 Jan 2008 02:07:51 +0900 (JST) From: Mail Delivery Subsystem Message-Id: <200801111707.CVQ00834@mg01vsv.sv.jcnet.ad.jp> To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="CVQ00834.1200071271/mg01vsv.sv.jcnet.ad.jp" X-ASG-Orig-Subj: Returned mail: Recipient address rejected: User unknown in relay recipient table (from [10.1.0.189]) Subject: Returned mail: Recipient address rejected: User unknown in relay recipient table (from [10.1.0.189]) Auto-Submitted: auto-generated (failure) X-Barracuda-Connect: bounce.jcnet.ad.jp[218.219.80.234] X-Barracuda-Start-Time: 1200071288 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3725 1.0000 -0.0777 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.08 X-Barracuda-Spam-Status: No, SCORE=-0.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39241 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5477/Fri Jan 11 04:26:19 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14101 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@mg01vsv.sv.jcnet.ad.jp Precedence: bulk X-list: xfs This is a MIME-encapsulated message --CVQ00834.1200071271/mg01vsv.sv.jcnet.ad.jp The original message was received at Sat, 12 Jan 2008 02:07:40 +0900 (JST) from 222100.unitednetworx.com [87.121.18.100] (may be forged) ----- The following addresses had permanent delivery errors ----- --CVQ00834.1200071271/mg01vsv.sv.jcnet.ad.jp Content-Type: message/delivery-status Reporting-MTA: dns; mg01vsv.sv.jcnet.ad.jp Arrival-Date: Sat, 12 Jan 2008 02:07:40 +0900 (JST) Final-Recipient: RFC822; linuxx@c3-net.ne.jp Action: failed Status: 5.1.1 Remote-MTA: DNS; [10.1.0.189] Diagnostic-Code: SMTP; 550 5.1.1 : Recipient address rejected: User unknown in relay recipient table Last-Attempt-Date: Sat, 12 Jan 2008 02:07:51 +0900 (JST) --CVQ00834.1200071271/mg01vsv.sv.jcnet.ad.jp Content-Type: message/rfc822 Return-Path: Received: from n-force (222100.unitednetworx.com [87.121.18.100] (may be forged)) by mg01vsv.sv.jcnet.ad.jp (MOS 3.7.3a-GA) with SMTP id CVQ00699; Sat, 12 Jan 2008 02:07:39 +0900 (JST) Date: Sat, 12 Jan 2008 02:07:38 +0900 (JST) X-Originating-IP: [17.6.47.99] X-Originating-Email: [linuxx@c3-net.ne.jp] X-Sender: linuxx@c3-net.ne.jp Received: (qmail 2953 by uid 477); Fri, 11 Jan 2008 07:08:30 +0200 Message-Id: <20080111090830.2955.qmail@n-force> To: Subject: SALE 74% OFF on Pfizer From: "admin@Viagra.com" --CVQ00834.1200071271/mg01vsv.sv.jcnet.ad.jp-- From owner-xfs@oss.sgi.com Fri Jan 11 09:19:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Jan 2008 09:19:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0BHJNa0005076 for ; Fri, 11 Jan 2008 09:19:25 -0800 X-ASG-Debug-ID: 1200071978-135e01630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fipprd08.prodigy.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6ED6D11B9334 for ; Fri, 11 Jan 2008 09:19:38 -0800 (PST) Received: from fipprd08.prodigy.net (fipprd08.sbcis.sbc.com [207.115.20.91]) by cuda.sgi.com with ESMTP id nYIHT3i8rEVjZ78S for ; Fri, 11 Jan 2008 09:19:38 -0800 (PST) Received: (from root@localhost) by fipprd08.prodigy.net (8.13.6 out.dk/8.13.6) id m0BHJbHT058972 for xfs@oss.sgi.com; Fri, 11 Jan 2008 09:19:37 -0800 From: MAILER-DAEMON@prodigy.net Message-Id: <200801111719.m0BHJbHT058972@fipprd08.prodigy.net> Date: Fri, 11 Jan 2008 09:19:35 -0800 X-ASG-Orig-Subj: Returned mail: Report Subject: Returned mail: Report To: X-Barracuda-Connect: fipprd08.sbcis.sbc.com[207.115.20.91] X-Barracuda-Start-Time: 1200071981 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4992 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.83 X-Barracuda-Spam-Status: No, SCORE=0.83 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=MAILTO_TO_SPAM_ADDR, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39241 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV 0.91.2/5478/Fri Jan 11 07:39:22 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14102 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@prodigy.net Precedence: bulk X-list: xfs User's mailbox is full: Unable to deliver mail. From owner-xfs@oss.sgi.com Fri Jan 11 12:58:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Jan 2008 12:58:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0BKvxiA024717 for ; Fri, 11 Jan 2008 12:58:01 -0800 X-ASG-Debug-ID: 1200085093-468703700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from jackfruit.srv.cs.cmu.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0C77050EA3F for ; Fri, 11 Jan 2008 12:58:13 -0800 (PST) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by cuda.sgi.com with ESMTP id Pg28eMC534BJSWAw for ; Fri, 11 Jan 2008 12:58:13 -0800 (PST) Received: from loganberry.srv.cs.cmu.edu (LOGANBERRY.SRV.CS.CMU.EDU [128.2.222.194]) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0BGhin9014107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jan 2008 11:43:44 -0500 (EST) Received: from LOGANBERRY.SRV.CS.CMU.EDU (localhost [127.0.0.1]) by loganberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0BGhiWj022220 for ; Fri, 11 Jan 2008 11:43:44 -0500 (EST) X-ASG-Orig-Subj: [PMX:VIRUS] Returned mail: see transcript for details Subject: [PMX:VIRUS] Returned mail: see transcript for details From: connectionists-owner@cs.cmu.edu To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0431357774==" Message-ID: Date: Fri, 11 Jan 2008 09:38:42 -0500 Precedence: bulk X-BeenThere: connectionists@cs.cmu.edu X-Mailman-Version: 2.1.6 X-Barracuda-Connect: JACKFRUIT.SRV.CS.CMU.EDU[128.2.201.16] X-Barracuda-Start-Time: 1200085097 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0017 1.0000 -2.0099 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.96 X-Barracuda-Spam-Status: No, SCORE=-0.96 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_RULE7568M, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39256 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/5478/Fri Jan 11 07:39:22 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14103 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: connectionists-owner@cs.cmu.edu Precedence: bulk X-list: xfs --===============0431357774== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at connectionists-owner@cs.cmu.edu. --===============0431357774== Content-Type: message/rfc822 MIME-Version: 1.0 Received: from raisinbran.srv.cs.cmu.edu (RAISINBRAN.SRV.CS.CMU.EDU [128.2.200.9]) by loganberry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0BEaDUv007013 for ; Fri, 11 Jan 2008 09:37:38 -0500 (EST) Received: from oss.sgi.com (catv-506345a6.catv.broadband.hu [80.99.69.166]) by raisinbran.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m0BBssLh016103 for ; Fri, 11 Jan 2008 06:55:04 -0500 (EST) Message-Id: <200801111155.m0BBssLh016103@raisinbran.srv.cs.cmu.edu> From: xfs@oss.sgi.com To: connectionists@cs.cmu.edu Subject: [PMX:VIRUS] Returned mail: see transcript for details Date: Fri, 11 Jan 2008 12:53:51 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_804642CF.453679A4" 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-PMX-Version: 5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.1.11.33257 X-PerlMx-Virus-Detected: W32/MyDoom-O This is a multi-part message in MIME format. ------=_NextPart_000_0012_804642CF.453679A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The message was undeliverable due to the following reason: Your message could not be delivered because the destination server was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 3 days: Host 85.78.120.123 is not responding. The following recipients could not receive this message: Please reply to postmaster@oss.sgi.com if you feel this message to be in error. ------=_NextPart_000_0012_804642CF.453679A4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The original content of this message part has been replaced by this text because it tested positive for the following virus(es): W32/MyDoom-O, W32/MyDoom-O The original message has been quarantined pending further action by the mail administrator. For further information about the message and its delivery status, please contact the undersigned, and include the full content of this message. The identifier for this message is 'm0BBssLh016103'. This notification is being sent to you and any other original envelope recipient(s). To avoid creating a nuisance and to keep mail traffic under control, the original sender of the message has NOT been notified. However, you may want to notify the sender at your discretion. The Management PureMessage Admin ------=_NextPart_000_0012_804642CF.453679A4-- --===============0431357774==-- From owner-xfs@oss.sgi.com Fri Jan 11 14:24:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 11 Jan 2008 14:25:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0BMOXcs000402 for ; Fri, 11 Jan 2008 14:24:36 -0800 X-ASG-Debug-ID: 1200090290-142100430000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CD14150F402 for ; Fri, 11 Jan 2008 14:24:50 -0800 (PST) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id 8Kg6yiB299TQ143Y for ; Fri, 11 Jan 2008 14:24:50 -0800 (PST) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m0BMH3Wb018900 for ; Fri, 11 Jan 2008 14:17:04 -0800 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m0BMGwL3002040 for ; Fri, 11 Jan 2008 14:16:58 -0800 Received: from [10.123.4.142] ([10.123.4.142]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Jan 2008 14:17:21 -0800 Message-ID: <4787EAF1.4080305@agami.com> Date: Fri, 11 Jan 2008 14:17:21 -0800 From: Michael Nishimoto User-Agent: Mail/News 1.5.0.4 (X11/20060629) MIME-Version: 1.0 To: Russell Cattelan CC: XFS Mailing List X-ASG-Orig-Subj: Re: CVS access down? Subject: Re: CVS access down? References: <4786D35C.9030104@thebarn.com> In-Reply-To: <4786D35C.9030104@thebarn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2008 22:17:21.0560 (UTC) FILETIME=[BC4AA180:01C8549F] X-Scanned-By: MIMEDefang 2.58 on 192.168.168.13 X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1200090290 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1420 1.0000 -1.1466 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.15 X-Barracuda-Spam-Status: No, SCORE=-1.15 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39261 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5478/Fri Jan 11 07:39:22 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14104 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miken@agami.com Precedence: bulk X-list: xfs Russell Cattelan wrote: > Michael Nishimoto wrote: > > It appears that CVS access is down. Can someone please take > > a look to see what's broken? > > > > Thanks! > > > Anymore info? > I just did quick test > cvs -d :pserver:cvs@oss.sgi.com:/cvs co xfs-cmds > > seems to be working fine for me. > > -Russell Sorry, it ends up that this was my fault. Michael From owner-xfs@oss.sgi.com Sat Jan 12 17:46:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 12 Jan 2008 17:46:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0D1kjmI021289 for ; Sat, 12 Jan 2008 17:46:47 -0800 X-ASG-Debug-ID: 1200188821-363400210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ns1.anodized.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E57F3512BF0 for ; Sat, 12 Jan 2008 17:47:01 -0800 (PST) Received: from ns1.anodized.com (ns1.anodized.com [204.15.208.61]) by cuda.sgi.com with ESMTP id oaIBHPtLJVFurhrY for ; Sat, 12 Jan 2008 17:47:01 -0800 (PST) Received: from ns1.anodized.com (localhost [127.0.0.1]) by ns1.anodized.com (8.13.1/8.13.1) with ESMTP id m0D1l0XH031205 for ; Sat, 12 Jan 2008 17:47:00 -0800 Received: from 127.0.0.1 ([127.0.0.1] helo=ns1.anodized.com) by ASSP-nospam; 12 Jan 2008 17:47:00 -0800 Received: (from clayne@localhost) by ns1.anodized.com (8.13.1/8.13.1/Submit) id m0D1l0Ql031202 for xfs@oss.sgi.com; Sat, 12 Jan 2008 17:47:00 -0800 Date: Sat, 12 Jan 2008 17:46:59 -0800 From: Christopher Layne To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_fsr: circular dependency under 2.6.24-rc6 Subject: xfs_fsr: circular dependency under 2.6.24-rc6 Message-ID: <20080113014659.GO26626@ns1.anodized.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Assp-Spam-Prob: 0.00000 X-Assp-Whitelisted: Yes X-Assp-Envelope-From: clayne@ns1.anodized.com X-Assp-Intended-For: xfs@oss.sgi.com X-Barracuda-Connect: ns1.anodized.com[204.15.208.61] X-Barracuda-Start-Time: 1200188822 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39372 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/5479/Sat Jan 12 15:08:34 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14105 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: clayne@anodized.com Precedence: bulk X-list: xfs ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.24-rc6 #1 ------------------------------------------------------- xfs_fsr/5694 is trying to acquire lock: (&mm->mmap_sem){----}, at: [] dio_get_page+0x4b/0x184 but task is already holding lock: (&(&ip->i_iolock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x8d which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&(&ip->i_iolock)->mr_lock){----}: [] __lock_acquire+0xb2b/0xd3f [] xfs_ilock+0x26/0x8d [] lock_acquire+0x84/0xa8 [] xfs_ilock+0x26/0x8d [] mark_held_locks+0x58/0x72 [] down_write_nested+0x39/0x45 [] xfs_ilock+0x26/0x8d [] xfs_ireclaim+0x37/0x7a [] xfs_finish_reclaim+0x15d/0x16b [] xfs_fs_clear_inode+0xca/0xeb [] clear_inode+0x94/0xeb [] dispose_list+0x58/0xfa [] invalidate_inodes+0xd9/0xf7 [] generic_shutdown_super+0x39/0xf3 [] kill_block_super+0xd/0x1e [] deactivate_super+0x49/0x61 [] sys_umount+0x1f5/0x206 [] trace_hardirqs_on_thunk+0x35/0x3a [] trace_hardirqs_on+0x121/0x14c [] trace_hardirqs_on_thunk+0x35/0x3a [] system_call+0x7e/0x83 [] 0xffffffffffffffff -> #1 (iprune_mutex){--..}: [] __lock_acquire+0xb2b/0xd3f [] shrink_icache_memory+0x42/0x214 [] lock_acquire+0x84/0xa8 [] shrink_icache_memory+0x42/0x214 [] __lock_acquire+0xd1e/0xd3f [] shrink_icache_memory+0x42/0x214 [] mutex_lock_nested+0xfd/0x297 [] prune_dcache+0xd8/0x184 [] shrink_icache_memory+0x42/0x214 [] shrink_slab+0xe7/0x15a [] try_to_free_pages+0x17a/0x24b [] __alloc_pages+0x208/0x34e [] handle_mm_fault+0x211/0x66d [] do_page_fault+0x3bd/0x743 [] __up_write+0x21/0x112 [] __up_write+0x21/0x112 [] _spin_unlock_irqrestore+0x3e/0x44 [] trace_hardirqs_on_thunk+0x35/0x3a [] trace_hardirqs_on+0x121/0x14c [] error_exit+0x0/0xa9 [] 0xffffffffffffffff -> #0 (&mm->mmap_sem){----}: [] __lock_acquire+0xa30/0xd3f [] dio_get_page+0x4b/0x184 [] lock_acquire+0x84/0xa8 [] dio_get_page+0x4b/0x184 [] down_read+0x32/0x3b [] dio_get_page+0x4b/0x184 [] __spin_lock_init+0x29/0x47 [] __blockdev_direct_IO+0x3fc/0x9c6 [] lockdep_init_map+0x8f/0x460 [] xfs_vm_direct_IO+0x101/0x134 [] xfs_get_blocks_direct+0x0/0x11 [] xfs_end_io_direct+0x0/0x82 [] __up_write+0x21/0x112 [] generic_file_direct_IO+0xcd/0x103 [] generic_file_direct_write+0x60/0xfd [] xfs_write+0x4ed/0x760 [] xfs_iunlock+0x37/0x85 [] xfs_read+0x1f1/0x210 [] do_sync_write+0xd1/0x118 [] __lock_acquire+0xd1e/0xd3f [] autoremove_wake_function+0x0/0x2e [] dnotify_parent+0x1f/0x6d [] vfs_write+0xad/0x136 [] sys_write+0x45/0x6e [] system_call+0x7e/0x83 [] 0xffffffffffffffff other info that might help us debug this: 1 lock held by xfs_fsr/5694: #0: (&(&ip->i_iolock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x8d stack backtrace: Pid: 5694, comm: xfs_fsr Not tainted 2.6.24-rc6 #1 Call Trace: [] print_circular_bug_tail+0x69/0x72 [] __lock_acquire+0xa30/0xd3f [] dio_get_page+0x4b/0x184 [] lock_acquire+0x84/0xa8 [] dio_get_page+0x4b/0x184 [] down_read+0x32/0x3b [] dio_get_page+0x4b/0x184 [] __spin_lock_init+0x29/0x47 [] __blockdev_direct_IO+0x3fc/0x9c6 [] lockdep_init_map+0x8f/0x460 [] xfs_vm_direct_IO+0x101/0x134 [] xfs_get_blocks_direct+0x0/0x11 [] xfs_end_io_direct+0x0/0x82 [] __up_write+0x21/0x112 [] generic_file_direct_IO+0xcd/0x103 [] generic_file_direct_write+0x60/0xfd [] xfs_write+0x4ed/0x760 [] xfs_iunlock+0x37/0x85 [] xfs_read+0x1f1/0x210 [] do_sync_write+0xd1/0x118 [] __lock_acquire+0xd1e/0xd3f [] autoremove_wake_function+0x0/0x2e [] dnotify_parent+0x1f/0x6d [] vfs_write+0xad/0x136 [] sys_write+0x45/0x6e [] system_call+0x7e/0x83 -- xfs issue or kernel issue? -cl From owner-xfs@oss.sgi.com Sun Jan 13 08:23:33 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 08:23:37 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0DGNVvv009221 for ; Sun, 13 Jan 2008 08:23:33 -0800 X-ASG-Debug-ID: 1200241428-55eb039b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from harold.telenet-ops.be (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B570A514390 for ; Sun, 13 Jan 2008 08:23:48 -0800 (PST) Received: from harold.telenet-ops.be (harold.telenet-ops.be [195.130.133.65]) by cuda.sgi.com with ESMTP id JU1jGEMwevmFKoYI for ; Sun, 13 Jan 2008 08:23:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by harold.telenet-ops.be (Postfix) with SMTP id 6039C3004E for ; Sun, 13 Jan 2008 17:23:15 +0100 (CET) Received: from 78-20-142-234.access.telenet.be (78-20-142-234.access.telenet.be [78.20.142.234]) by harold.telenet-ops.be (Postfix) with ESMTP id 540BF30024 for ; Sun, 13 Jan 2008 17:23:15 +0100 (CET) From: "Grozdan Nikolov (openSUSE Linux)" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Cannot delete a directory on a XFS file system Subject: Cannot delete a directory on a XFS file system Date: Sun, 13 Jan 2008 17:23:12 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801131723.12626.microchip@telenet.be> X-Barracuda-Connect: harold.telenet-ops.be[195.130.133.65] X-Barracuda-Start-Time: 1200241428 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39429 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5480/Sun Jan 13 05:17:55 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14106 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: microchip@telenet.be Precedence: bulk X-list: xfs Hi, I have a small problem with XFS on a small 40 GB IDE disk that I use for my music collection. The disk (/dev/hdb) has only one partition on it formatted as XFS. On this partition, there is a directory that no matter what I do, I cannot delete it. I tried everything, in Konqueror, right-click on the directory and choose to delete it. As root on the console doing "rm -rf /media/data/DATA/MusicApps" ... but nothing works. When I try to "rm -rf" on this directory I get a message saying... rm: cannot remove directory `MusicApps/Loops/loops/Acid Loops/Bass': Directory not empty But the "Bass" directory is completely empty, there's nothing in there. Also when I unmount the file system and do a "xfs_check /dev/hdb1" I get a message saying... link count mismatch for inode 184549517 (name ?), nlink 3, counted 2 I did several times "xfs_repair /dev/hdb1" but I still get the same result. xfs_check reports the same message and I still can't get rid of this empty directory. I'm using kernel 2.6.24-rc7, but it's the same with other kernels. I also did check the partition for bad block with the "badblocks" program, but nothing came out, so the disk is just fine. Any ideas how I can delete this directory? From owner-xfs@oss.sgi.com Sun Jan 13 11:49:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 11:49:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0DJnhJm024261 for ; Sun, 13 Jan 2008 11:49:47 -0800 X-ASG-Debug-ID: 1200253801-5b5f01730000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7C00E514CAF for ; Sun, 13 Jan 2008 11:50:01 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id ZBi8shzv2JgQyta0 for ; Sun, 13 Jan 2008 11:50:01 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 0A3B61C003F2E; Sun, 13 Jan 2008 14:49:30 -0500 (EST) Date: Sun, 13 Jan 2008 14:49:30 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: "Grozdan Nikolov (openSUSE Linux)" cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Cannot delete a directory on a XFS file system Subject: Re: Cannot delete a directory on a XFS file system In-Reply-To: <200801131723.12626.microchip@telenet.be> Message-ID: References: <200801131723.12626.microchip@telenet.be> User-Agent: Alpine 0.999999 (DEB 847 2007-12-06) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1200253801 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39444 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5481/Sun Jan 13 10:04:16 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14107 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 13 Jan 2008, Grozdan Nikolov (openSUSE Linux) wrote: > Hi, > > I have a small problem with XFS on a small 40 GB IDE disk that I use for my > music collection. The disk (/dev/hdb) has only one partition on it formatted > as XFS. On this partition, there is a directory that no matter what I do, I > cannot delete it. I tried everything, in Konqueror, right-click on the > directory and choose to delete it. As root on the console > doing "rm -rf /media/data/DATA/MusicApps" ... but nothing works. > > When I try to "rm -rf" on this directory I get a message saying... > > rm: cannot remove directory `MusicApps/Loops/loops/Acid Loops/Bass': Directory > not empty > > But the "Bass" directory is completely empty, there's nothing in there. Also > when I unmount the file system and do a "xfs_check /dev/hdb1" I get a message > saying... > > link count mismatch for inode 184549517 (name ?), nlink 3, counted 2 > > I did several times "xfs_repair /dev/hdb1" but I still get the same result. > xfs_check reports the same message and I still can't get rid of this empty > directory. I'm using kernel 2.6.24-rc7, but it's the same with other kernels. > I also did check the partition for bad block with the "badblocks" program, > but nothing came out, so the disk is just fine. > > Any ideas how I can delete this directory? > > The developers get in on Monday :P But some things they will ask: 1. run xfs_info /dev/hdb1 2. run (and capture the full output from the repair process) 3. run ls -lR on the dir that has problems 4. run ls -li on the director(ies) that cannot be deleted for the inode #s If you give them this information in advance they'll have more info to help you. Justin. From owner-xfs@oss.sgi.com Sun Jan 13 13:26:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 13:26:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0DLQhnC005314 for ; Sun, 13 Jan 2008 13:26:47 -0800 X-ASG-Debug-ID: 1200259620-1dc400410000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from harold.telenet-ops.be (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 75DAF5150A6 for ; Sun, 13 Jan 2008 13:27:00 -0800 (PST) Received: from harold.telenet-ops.be (harold.telenet-ops.be [195.130.133.65]) by cuda.sgi.com with ESMTP id MUDHghIjkrgdTA2U for ; Sun, 13 Jan 2008 13:27:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by harold.telenet-ops.be (Postfix) with SMTP id 4788830044; Sun, 13 Jan 2008 22:26:59 +0100 (CET) Received: from 78-20-142-234.access.telenet.be (78-20-142-234.access.telenet.be [78.20.142.234]) by harold.telenet-ops.be (Postfix) with ESMTP id 2FEAC3003E; Sun, 13 Jan 2008 22:26:59 +0100 (CET) From: "Grozdan Nikolov (openSUSE Linux)" To: Justin Piszcz X-ASG-Orig-Subj: Re: Cannot delete a directory on a XFS file system Subject: Re: Cannot delete a directory on a XFS file system Date: Sun, 13 Jan 2008 22:26:59 +0100 User-Agent: KMail/1.9.5 References: <200801131723.12626.microchip@telenet.be> In-Reply-To: Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200801132226.59652.microchip@telenet.be> X-Barracuda-Connect: harold.telenet-ops.be[195.130.133.65] X-Barracuda-Start-Time: 1200259621 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39450 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5481/Sun Jan 13 10:04:16 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m0DLQlnC005320 X-archive-position: 14108 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: microchip@telenet.be Precedence: bulk X-list: xfs On Sunday 13 January 2008 20:49, you wrote: > On Sun, 13 Jan 2008, Grozdan Nikolov (openSUSE Linux) wrote: > > Hi, > > > > I have a small problem with XFS on a small 40 GB IDE disk that I use for > > my music collection. The disk (/dev/hdb) has only one partition on it > > formatted as XFS. On this partition, there is a directory that no matter > > what I do, I cannot delete it. I tried everything, in Konqueror, > > right-click on the directory and choose to delete it. As root on the > > console > > doing "rm -rf /media/data/DATA/MusicApps" ... but nothing works. > > > > When I try to "rm -rf" on this directory I get a message saying... > > > > rm: cannot remove directory `MusicApps/Loops/loops/Acid Loops/Bass': > > Directory not empty > > > > But the "Bass" directory is completely empty, there's nothing in there. > > Also when I unmount the file system and do a "xfs_check /dev/hdb1" I get > > a message saying... > > > > link count mismatch for inode 184549517 (name ?), nlink 3, counted 2 > > > > I did several times "xfs_repair /dev/hdb1" but I still get the same > > result. xfs_check reports the same message and I still can't get rid of > > this empty directory. I'm using kernel 2.6.24-rc7, but it's the same with > > other kernels. I also did check the partition for bad block with the > > "badblocks" program, but nothing came out, so the disk is just fine. > > > > Any ideas how I can delete this directory? > > The developers get in on Monday :P > > But some things they will ask: > > 1. run xfs_info /dev/hdb1 meta-data=/dev/hdb1              isize=256    agcount=16, agsize=610595 blks          =                       sectsz=512   attr=0 data     =                       bsize=4096   blocks=9769520, imaxpct=25          =                       sunit=0      swidth=0 blks, unwritten=1 naming   =version 2              bsize=4096 log      =internal               bsize=4096   blocks=4770, version=1          =                       sectsz=512   sunit=0 blks realtime =none                   extsz=65536  blocks=0, rtextents=0 > 2. run (and capture the full output from the repair process) Phase 1 - find and verify superblock... Phase 2 - using internal log         - zero log...         - scan filesystem freespace and inode maps...         - found root inode chunk Phase 3 - for each AG...         - scan and clear agi unlinked lists...         - process known inodes and perform inode discovery...         - agno = 0         - agno = 1         - agno = 2         - agno = 3         - agno = 4         - agno = 5         - agno = 6         - agno = 7         - agno = 8         - agno = 9         - agno = 10         - agno = 11         - agno = 12         - agno = 13         - agno = 14         - agno = 15         - process newly discovered inodes... Phase 4 - check for duplicate blocks...         - setting up duplicate extent list...         - clear lost+found (if it exists) ...         - check for inodes claiming duplicate blocks...         - agno = 0         - agno = 1         - agno = 2         - agno = 3         - agno = 4         - agno = 5         - agno = 6         - agno = 7         - agno = 8         - agno = 9         - agno = 10         - agno = 11         - agno = 12         - agno = 13         - agno = 14         - agno = 15 Phase 5 - rebuild AG headers and trees...         - reset superblock... Phase 6 - check inode connectivity...         - resetting contents of realtime bitmap and summary inodes         - ensuring existence of lost+found directory         - traversing filesystem starting at / ...         - traversal finished ...         - traversing all unattached subtrees ...         - traversals finished ...         - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done > 3. run ls -lR on the dir that has problems MusicApps: total 0 drwxr-xr-x 3 microchip users 18 2007-12-16 02:02 Loops MusicApps/Loops: total 0 drwxr-xr-x 3 microchip users 23 2007-12-16 02:02 loops MusicApps/Loops/loops: total 0 drwxr-xr-x 3 microchip users 17 2007-12-16 02:02 Acid Loops MusicApps/Loops/loops/Acid Loops: total 0 drwxr-xr-x 3 microchip users 6 2007-12-16 02:02 Bass MusicApps/Loops/loops/Acid Loops/Bass: total 0 > 4. run ls -li on the director(ies) that cannot be deleted for the inode #s total 0 201326732 drwxr-xr-x 3 microchip users 18 2007-12-16 02:02 Loops > > If you give them this information in advance they'll have more info to > help you. > > Justin. From owner-xfs@oss.sgi.com Sun Jan 13 13:27:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 13:27:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0DLRcAs005480 for ; Sun, 13 Jan 2008 13:27:41 -0800 X-ASG-Debug-ID: 1200259676-6f8500bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E14E75150AF for ; Sun, 13 Jan 2008 13:27:56 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id A7uo4m6kTkYGcZDh for ; Sun, 13 Jan 2008 13:27:56 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id CA87518CFB083; Sun, 13 Jan 2008 15:27:54 -0600 (CST) Message-ID: <478A8256.8030000@sandeen.net> Date: Sun, 13 Jan 2008 15:27:50 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Justin Piszcz CC: "Grozdan Nikolov (openSUSE Linux)" , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Cannot delete a directory on a XFS file system Subject: Re: Cannot delete a directory on a XFS file system References: <200801131723.12626.microchip@telenet.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1200259676 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39450 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5481/Sun Jan 13 10:04:16 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14109 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Justin Piszcz wrote: > > On Sun, 13 Jan 2008, Grozdan Nikolov (openSUSE Linux) wrote: > >> Hi, >> >> I have a small problem with XFS on a small 40 GB IDE disk that I use for my >> music collection. The disk (/dev/hdb) has only one partition on it formatted >> as XFS. On this partition, there is a directory that no matter what I do, I >> cannot delete it. I tried everything, in Konqueror, right-click on the >> directory and choose to delete it. As root on the console >> doing "rm -rf /media/data/DATA/MusicApps" ... but nothing works. >> >> When I try to "rm -rf" on this directory I get a message saying... >> >> rm: cannot remove directory `MusicApps/Loops/loops/Acid Loops/Bass': Directory >> not empty >> >> But the "Bass" directory is completely empty, there's nothing in there. Also >> when I unmount the file system and do a "xfs_check /dev/hdb1" I get a message >> saying... >> >> link count mismatch for inode 184549517 (name ?), nlink 3, counted 2 >> >> I did several times "xfs_repair /dev/hdb1" but I still get the same result. >> xfs_check reports the same message and I still can't get rid of this empty >> directory. I'm using kernel 2.6.24-rc7, but it's the same with other kernels. >> I also did check the partition for bad block with the "badblocks" program, >> but nothing came out, so the disk is just fine. >> >> Any ideas how I can delete this directory? >> >> > > The developers get in on Monday :P > > But some things they will ask: > > 1. run xfs_info /dev/hdb1 > 2. run (and capture the full output from the repair process) ... with very latest xfsprogs please. If latest repair doesn't fix it, using xfs_metadump to provide a filesystem image for Barry to reproduce with would be helpful. > 3. run ls -lR on the dir that has problems > 4. run ls -li on the director(ies) that cannot be deleted for the inode #s ls -a on the dir to be sure there are no hidden dotfiles ls -id on the dir to see if it is inode 184549517 -Eric From owner-xfs@oss.sgi.com Sun Jan 13 13:38:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 13:38:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0DLcZBW007157 for ; Sun, 13 Jan 2008 13:38:37 -0800 X-ASG-Debug-ID: 1200260332-244c004c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from edna.telenet-ops.be (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7CA4411CA579 for ; Sun, 13 Jan 2008 13:38:52 -0800 (PST) Received: from edna.telenet-ops.be (edna.telenet-ops.be [195.130.132.58]) by cuda.sgi.com with ESMTP id SdDHXkAeiQe70VwR for ; Sun, 13 Jan 2008 13:38:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by edna.telenet-ops.be (Postfix) with SMTP id 0F13FE406F; Sun, 13 Jan 2008 22:38:52 +0100 (CET) Received: from 78-20-142-234.access.telenet.be (78-20-142-234.access.telenet.be [78.20.142.234]) by edna.telenet-ops.be (Postfix) with ESMTP id F2A8BE4042; Sun, 13 Jan 2008 22:38:51 +0100 (CET) From: "Grozdan Nikolov (openSUSE Linux)" To: Eric Sandeen X-ASG-Orig-Subj: Re: Cannot delete a directory on a XFS file system Subject: Re: Cannot delete a directory on a XFS file system Date: Sun, 13 Jan 2008 22:38:51 +0100 User-Agent: KMail/1.9.5 References: <200801131723.12626.microchip@telenet.be> <478A8256.8030000@sandeen.net> In-Reply-To: <478A8256.8030000@sandeen.net> Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801132238.52075.microchip@telenet.be> X-Barracuda-Connect: edna.telenet-ops.be[195.130.132.58] X-Barracuda-Start-Time: 1200260333 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39451 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5481/Sun Jan 13 10:04:16 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14110 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: microchip@telenet.be Precedence: bulk X-list: xfs On Sunday 13 January 2008 22:27, you wrote: > Justin Piszcz wrote: > > On Sun, 13 Jan 2008, Grozdan Nikolov (openSUSE Linux) wrote: > >> Hi, > >> > >> I have a small problem with XFS on a small 40 GB IDE disk that I use for > >> my music collection. The disk (/dev/hdb) has only one partition on it > >> formatted as XFS. On this partition, there is a directory that no matter > >> what I do, I cannot delete it. I tried everything, in Konqueror, > >> right-click on the directory and choose to delete it. As root on the > >> console > >> doing "rm -rf /media/data/DATA/MusicApps" ... but nothing works. > >> > >> When I try to "rm -rf" on this directory I get a message saying... > >> > >> rm: cannot remove directory `MusicApps/Loops/loops/Acid Loops/Bass': > >> Directory not empty > >> > >> But the "Bass" directory is completely empty, there's nothing in there. > >> Also when I unmount the file system and do a "xfs_check /dev/hdb1" I get > >> a message saying... > >> > >> link count mismatch for inode 184549517 (name ?), nlink 3, counted 2 > >> > >> I did several times "xfs_repair /dev/hdb1" but I still get the same > >> result. xfs_check reports the same message and I still can't get rid of > >> this empty directory. I'm using kernel 2.6.24-rc7, but it's the same > >> with other kernels. I also did check the partition for bad block with > >> the "badblocks" program, but nothing came out, so the disk is just fine. > >> > >> Any ideas how I can delete this directory? > > > > The developers get in on Monday :P > > > > But some things they will ask: > > > > 1. run xfs_info /dev/hdb1 > > 2. run (and capture the full output from the repair process) > > ... with very latest xfsprogs please. If latest repair doesn't fix it, I do not know what version is the latest of xfsprogs. I use my distro's default (2.8.11) > using xfs_metadump to provide a filesystem image for Barry to reproduce > with would be helpful. I can't find xfs_metadump on my system. I only have xfsdump. Is this the same? > > > 3. run ls -lR on the dir that has problems > > 4. run ls -li on the director(ies) that cannot be deleted for the inode > > #s > > ls -a on the dir to be sure there are no hidden dotfiles ls -a MusicApps . .. Loops ls -a "MusicApps/Loops/loops/Acid Loops/Bass" . .. > ls -id on the dir to see if it is inode 184549517 ls -id "MusicApps/Loops/loops/Acid Loops/Bass" 184549517 MusicApps/Loops/loops/Acid Loops/Bass > > -Eric From owner-xfs@oss.sgi.com Sun Jan 13 13:51:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 13:52:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0DLpgbo008485 for ; Sun, 13 Jan 2008 13:51:45 -0800 X-ASG-Debug-ID: 1200261119-456c00040000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7022411CA622 for ; Sun, 13 Jan 2008 13:52:00 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id yFpNzj2i9aNxsG8l for ; Sun, 13 Jan 2008 13:52:00 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4D12F18CFB06D; Sun, 13 Jan 2008 15:51:58 -0600 (CST) Message-ID: <478A87FD.60203@sandeen.net> Date: Sun, 13 Jan 2008 15:51:57 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Grozdan Nikolov (openSUSE Linux)" CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Cannot delete a directory on a XFS file system Subject: Re: Cannot delete a directory on a XFS file system References: <200801131723.12626.microchip@telenet.be> <478A8256.8030000@sandeen.net> <200801132238.52075.microchip@telenet.be> In-Reply-To: <200801132238.52075.microchip@telenet.be> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1200261120 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39451 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5481/Sun Jan 13 10:04:16 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14111 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Grozdan Nikolov (openSUSE Linux) wrote: > I do not know what version is the latest of xfsprogs. I use my distro's > default (2.8.11) Ok, 2.9.4 is latest. 2.8.11 is from Aug 2006.... Perhaps the more recent version will properly fix your fs. From the changelog: xfsprogs-2.8.15 (19 October 2006) - Fix up nlink checks and repairs in phase 7 for xfs_repair. >> using xfs_metadump to provide a filesystem image for Barry to reproduce >> with would be helpful. > > I can't find xfs_metadump on my system. I only have xfsdump. Is this the same? Nope, it's not there in your older xfsprogs. >>> 3. run ls -lR on the dir that has problems >>> 4. run ls -li on the director(ies) that cannot be deleted for the inode >>> #s >> ls -a on the dir to be sure there are no hidden dotfiles > ls -a "MusicApps/Loops/loops/Acid Loops/Bass" > > . .. Ok, no hidden files. > >> ls -id on the dir to see if it is inode 184549517 > > ls -id "MusicApps/Loops/loops/Acid Loops/Bass" So, the dir you can't delete is the one with the link count mismatch stated by xfs_check - that's what I figured but wanted to double check. I'd be willing to bet that the latest xfsprogs would fix this for you. Alternately some xfs_db hackery could too, but using more recent repair would be the best route I think. -Eric > 184549517 MusicApps/Loops/loops/Acid Loops/Bass > >> -Eric > From owner-xfs@oss.sgi.com Sun Jan 13 14:56:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 14:56:32 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0DMuQwR013348 for ; Sun, 13 Jan 2008 14:56:27 -0800 X-ASG-Debug-ID: 1200265000-740c00060000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from monty.telenet-ops.be (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E570311CA98A for ; Sun, 13 Jan 2008 14:56:40 -0800 (PST) Received: from monty.telenet-ops.be (monty.telenet-ops.be [195.130.132.56]) by cuda.sgi.com with ESMTP id BOdyu2yVYa2JyfYz for ; Sun, 13 Jan 2008 14:56:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by monty.telenet-ops.be (Postfix) with SMTP id 26F205403D; Sun, 13 Jan 2008 23:56:39 +0100 (CET) Received: from 78-20-142-234.access.telenet.be (78-20-142-234.access.telenet.be [78.20.142.234]) by monty.telenet-ops.be (Postfix) with ESMTP id 185435400C; Sun, 13 Jan 2008 23:56:38 +0100 (CET) From: "Grozdan Nikolov (openSUSE Linux)" To: Eric Sandeen X-ASG-Orig-Subj: Re: Cannot delete a directory on a XFS file system Subject: Re: Cannot delete a directory on a XFS file system Date: Sun, 13 Jan 2008 23:56:39 +0100 User-Agent: KMail/1.9.5 References: <200801131723.12626.microchip@telenet.be> <200801132238.52075.microchip@telenet.be> <478A87FD.60203@sandeen.net> In-Reply-To: <478A87FD.60203@sandeen.net> Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801132356.39966.microchip@telenet.be> X-Barracuda-Connect: monty.telenet-ops.be[195.130.132.56] X-Barracuda-Start-Time: 1200265003 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39454 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5481/Sun Jan 13 10:04:16 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14112 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: microchip@telenet.be Precedence: bulk X-list: xfs On Sunday 13 January 2008 22:51, you wrote: > Grozdan Nikolov (openSUSE Linux) wrote: > > I do not know what version is the latest of xfsprogs. I use my distro's > > default (2.8.11) > > Ok, 2.9.4 is latest. 2.8.11 is from Aug 2006.... Perhaps the more > recent version will properly fix your fs. > > From the changelog: > > xfsprogs-2.8.15 (19 October 2006) > - Fix up nlink checks and repairs in phase 7 for xfs_repair. ok, I added the latest version of xfsprogs from the SUSE build service, ran xfs_repair /dev/hdb1 and when it finished it resetted the inode... resetting inode 184549517 nlinks from 3 to 2 after this, I was able to delete the directory. Thank for all your help :) > > >> using xfs_metadump to provide a filesystem image for Barry to reproduce > >> with would be helpful. > > > > I can't find xfs_metadump on my system. I only have xfsdump. Is this the > > same? > > Nope, it's not there in your older xfsprogs. > > >>> 3. run ls -lR on the dir that has problems > >>> 4. run ls -li on the director(ies) that cannot be deleted for the inode > >>> #s > >> > >> ls -a on the dir to be sure there are no hidden dotfiles > > > > ls -a "MusicApps/Loops/loops/Acid Loops/Bass" > > > > . .. > > Ok, no hidden files. > > >> ls -id on the dir to see if it is inode 184549517 > > > > ls -id "MusicApps/Loops/loops/Acid Loops/Bass" > > So, the dir you can't delete is the one with the link count mismatch > stated by xfs_check - that's what I figured but wanted to double check. > > I'd be willing to bet that the latest xfsprogs would fix this for you. > > Alternately some xfs_db hackery could too, but using more recent repair > would be the best route I think. > > -Eric > > > 184549517 MusicApps/Loops/loops/Acid Loops/Bass > > > >> -Eric From owner-xfs@oss.sgi.com Sun Jan 13 16:15:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 16:16:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0E0Fm8u019119 for ; Sun, 13 Jan 2008 16:15:53 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA05184; Mon, 14 Jan 2008 11:16:00 +1100 Message-ID: <478AAA73.3080008@sgi.com> Date: Mon, 14 Jan 2008 11:18:59 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Christopher Layne CC: xfs@oss.sgi.com Subject: Re: xfs_fsr: circular dependency under 2.6.24-rc6 References: <20080113014659.GO26626@ns1.anodized.com> In-Reply-To: <20080113014659.GO26626@ns1.anodized.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14113 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christopher, This is a known dependency and is actually a false alarm. The inode that is being reclaimed (thread #2) cannot have writes in progress (thread #0) since they cannot involve the same i_iolock. We cannot change the code to work around this nor can we add lockdep annotations to avoid this case. You can safely ignore this lockdep report. Lachlan Christopher Layne wrote: > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.24-rc6 #1 > ------------------------------------------------------- > xfs_fsr/5694 is trying to acquire lock: > (&mm->mmap_sem){----}, at: [] dio_get_page+0x4b/0x184 > > but task is already holding lock: > (&(&ip->i_iolock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x8d > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #2 (&(&ip->i_iolock)->mr_lock){----}: > [] __lock_acquire+0xb2b/0xd3f > [] xfs_ilock+0x26/0x8d > [] lock_acquire+0x84/0xa8 > [] xfs_ilock+0x26/0x8d > [] mark_held_locks+0x58/0x72 > [] down_write_nested+0x39/0x45 > [] xfs_ilock+0x26/0x8d > [] xfs_ireclaim+0x37/0x7a > [] xfs_finish_reclaim+0x15d/0x16b > [] xfs_fs_clear_inode+0xca/0xeb > [] clear_inode+0x94/0xeb > [] dispose_list+0x58/0xfa > [] invalidate_inodes+0xd9/0xf7 > [] generic_shutdown_super+0x39/0xf3 > [] kill_block_super+0xd/0x1e > [] deactivate_super+0x49/0x61 > [] sys_umount+0x1f5/0x206 > [] trace_hardirqs_on_thunk+0x35/0x3a > [] trace_hardirqs_on+0x121/0x14c > [] trace_hardirqs_on_thunk+0x35/0x3a > [] system_call+0x7e/0x83 > [] 0xffffffffffffffff > > -> #1 (iprune_mutex){--..}: > [] __lock_acquire+0xb2b/0xd3f > [] shrink_icache_memory+0x42/0x214 > [] lock_acquire+0x84/0xa8 > [] shrink_icache_memory+0x42/0x214 > [] __lock_acquire+0xd1e/0xd3f > [] shrink_icache_memory+0x42/0x214 > [] mutex_lock_nested+0xfd/0x297 > [] prune_dcache+0xd8/0x184 > [] shrink_icache_memory+0x42/0x214 > [] shrink_slab+0xe7/0x15a > [] try_to_free_pages+0x17a/0x24b > [] __alloc_pages+0x208/0x34e > [] handle_mm_fault+0x211/0x66d > [] do_page_fault+0x3bd/0x743 > [] __up_write+0x21/0x112 > [] __up_write+0x21/0x112 > [] _spin_unlock_irqrestore+0x3e/0x44 > [] trace_hardirqs_on_thunk+0x35/0x3a > [] trace_hardirqs_on+0x121/0x14c > [] error_exit+0x0/0xa9 > [] 0xffffffffffffffff > > -> #0 (&mm->mmap_sem){----}: > [] __lock_acquire+0xa30/0xd3f > [] dio_get_page+0x4b/0x184 > [] lock_acquire+0x84/0xa8 > [] dio_get_page+0x4b/0x184 > [] down_read+0x32/0x3b > [] dio_get_page+0x4b/0x184 > [] __spin_lock_init+0x29/0x47 > [] __blockdev_direct_IO+0x3fc/0x9c6 > [] lockdep_init_map+0x8f/0x460 > [] xfs_vm_direct_IO+0x101/0x134 > [] xfs_get_blocks_direct+0x0/0x11 > [] xfs_end_io_direct+0x0/0x82 > [] __up_write+0x21/0x112 > [] generic_file_direct_IO+0xcd/0x103 > [] generic_file_direct_write+0x60/0xfd > [] xfs_write+0x4ed/0x760 > [] xfs_iunlock+0x37/0x85 > [] xfs_read+0x1f1/0x210 > [] do_sync_write+0xd1/0x118 > [] __lock_acquire+0xd1e/0xd3f > [] autoremove_wake_function+0x0/0x2e > [] dnotify_parent+0x1f/0x6d > [] vfs_write+0xad/0x136 > [] sys_write+0x45/0x6e > [] system_call+0x7e/0x83 > [] 0xffffffffffffffff > > other info that might help us debug this: > > 1 lock held by xfs_fsr/5694: > #0: (&(&ip->i_iolock)->mr_lock){----}, at: [] xfs_ilock+0x4d/0x8d > > stack backtrace: > Pid: 5694, comm: xfs_fsr Not tainted 2.6.24-rc6 #1 > > Call Trace: > [] print_circular_bug_tail+0x69/0x72 > [] __lock_acquire+0xa30/0xd3f > [] dio_get_page+0x4b/0x184 > [] lock_acquire+0x84/0xa8 > [] dio_get_page+0x4b/0x184 > [] down_read+0x32/0x3b > [] dio_get_page+0x4b/0x184 > [] __spin_lock_init+0x29/0x47 > [] __blockdev_direct_IO+0x3fc/0x9c6 > [] lockdep_init_map+0x8f/0x460 > [] xfs_vm_direct_IO+0x101/0x134 > [] xfs_get_blocks_direct+0x0/0x11 > [] xfs_end_io_direct+0x0/0x82 > [] __up_write+0x21/0x112 > [] generic_file_direct_IO+0xcd/0x103 > [] generic_file_direct_write+0x60/0xfd > [] xfs_write+0x4ed/0x760 > [] xfs_iunlock+0x37/0x85 > [] xfs_read+0x1f1/0x210 > [] do_sync_write+0xd1/0x118 > [] __lock_acquire+0xd1e/0xd3f > [] autoremove_wake_function+0x0/0x2e > [] dnotify_parent+0x1f/0x6d > [] vfs_write+0xad/0x136 > [] sys_write+0x45/0x6e > [] system_call+0x7e/0x83 > > > -- > > xfs issue or kernel issue? > > -cl > > > From owner-xfs@oss.sgi.com Sun Jan 13 19:53:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 13 Jan 2008 19:54:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0E3rpiC002745 for ; Sun, 13 Jan 2008 19:53:55 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA09497; Mon, 14 Jan 2008 14:54:04 +1100 Message-ID: <478ADD90.1000806@sgi.com> Date: Mon, 14 Jan 2008 14:57:04 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-dev , xfs-oss Subject: Re: [PATCH] make inode reclaim synchronise with xfs_iflush_done() References: <475F878D.6090407@sgi.com> <20071212230858.GO4612@sgi.com> In-Reply-To: <20071212230858.GO4612@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14114 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > (can ppl please post patches in line rather than as attachments > as it's really hard to quote attachments) > > On Wed, Dec 12, 2007 at 06:02:37PM +1100, Lachlan McIlroy wrote: >> On a forced shutdown, xfs_finish_reclaim() will skip flushing the inode. >> If the inode flush lock is not already held and there is an outstanding >> xfs_iflush_done() then we might free the inode prematurely. By acquiring >> and releasing the flush lock we will synchronise with xfs_iflush_done(). > > Yes, That could happen. Good catch. Comments on the code below. > >> Alternatively we could take a hold on the inode when when issuing I/Os >> with xfs_iflush_done() and release it in xfs_iflush_done(). Would this >> be a better approach? > > No - we can't take a hold on the inode because it may not have a linux > inode attached to it and hence there's nothing to hold the reference > count (we use the linux inode reference count for this). > > > --- fs/xfs/xfs_vnodeops.c_1.726 2007-12-12 17:14:59.000000000 +1100 > +++ fs/xfs/xfs_vnodeops.c 2007-12-12 17:15:42.000000000 +1100 > @@ -3762,20 +3762,29 @@ xfs_finish_reclaim( > goto reclaim; > } > xfs_iflock(ip); /* synchronize with xfs_iflush_done */ > + xfs_ifunlock(ip); > } > > Why do you unlock it here? If it is left locked, there is absolutely > no chance for the inode to be flushed again after this point. > > ASSERT(ip->i_update_core == 0); > ASSERT(ip->i_itemp == NULL || > ip->i_itemp->ili_format.ilf_fields == 0); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > - } else if (locked) { > + } else { > /* > * We are not interested in doing an iflush if we're > * in the process of shutting down the filesystem forcibly. > * So, just reclaim the inode. > - */ > - xfs_ifunlock(ip); > - xfs_iunlock(ip, XFS_ILOCK_EXCL); > + * > + * If the flush lock is not already held then temporarily > + * acquire it to synchronize with xfs_iflush_done. > + */ > + if (locked) { > + xfs_ifunlock(ip); > + xfs_iunlock(ip, XFS_ILOCK_EXCL); > + } else { > + xfs_iflock(ip); > + xfs_ifunlock(ip); > + } > } > > Oh, that just makes it messy :/ > > How about locking the inode unconditionally before the entire if..else > statement like: > > + if (!locked) { > + xfs_ilock(ip, XFS_ILOCK_EXCL); > + xfs_iflock(ip); > + } > if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) { > - if (!locked) { > - xfs_ilock(ip, XFS_ILOCK_EXCL); > - xfs_iflock(ip); > - } > > ..... > - } else if (locked) { > + } else { > /* > * We are not interested in doing an iflush if we're > * in the process of shutting down the filesystem forcibly. > * So, just reclaim the inode. > - xfs_ifunlock(ip); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > } > reclaim: > > That would mean we always go to xfs_ireclaim() with the flush lock held > and hence a guarantee that no more I/O can be issued on the inode. That would be a bad thing. We are about to tear the inode down and free the memory. If any threads are still waiting on the flush lock they will wait forever or eventually access freed memory. This patch cleans up the code a little further by removing the 'else if (locked)' case. --- fs/xfs/xfs_vnodeops.c_1.727 2008-01-10 16:00:48.000000000 +1100 +++ fs/xfs/xfs_vnodeops.c 2008-01-11 13:35:41.000000000 +1100 @@ -3721,12 +3721,12 @@ xfs_finish_reclaim( * We get the flush lock regardless, though, just to make sure * we don't free it while it is being flushed. */ - if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) { - if (!locked) { - xfs_ilock(ip, XFS_ILOCK_EXCL); - xfs_iflock(ip); - } + if (!locked) { + xfs_ilock(ip, XFS_ILOCK_EXCL); + xfs_iflock(ip); + } + if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) { if (ip->i_update_core || ((ip->i_itemp != NULL) && (ip->i_itemp->ili_format.ilf_fields != 0))) { @@ -3746,18 +3746,12 @@ xfs_finish_reclaim( ASSERT(ip->i_update_core == 0); ASSERT(ip->i_itemp == NULL || ip->i_itemp->ili_format.ilf_fields == 0); - xfs_iunlock(ip, XFS_ILOCK_EXCL); - } else if (locked) { - /* - * We are not interested in doing an iflush if we're - * in the process of shutting down the filesystem forcibly. - * So, just reclaim the inode. - */ - xfs_ifunlock(ip); - xfs_iunlock(ip, XFS_ILOCK_EXCL); } - reclaim: + xfs_ifunlock(ip); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + +reclaim: xfs_ireclaim(ip); return 0; } From owner-xfs@oss.sgi.com Mon Jan 14 04:14:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 04:14:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0ECE5OH020406 for ; Mon, 14 Jan 2008 04:14:08 -0800 X-ASG-Debug-ID: 1200312863-2a3703ab0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7BCC411CB10C for ; Mon, 14 Jan 2008 04:14:23 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by cuda.sgi.com with ESMTP id Aw5yJcHf6Zo7Ia3e for ; Mon, 14 Jan 2008 04:14:23 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so3886730waf.18 for ; Mon, 14 Jan 2008 04:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=RiWCLQA+GUNeyZ8+SGYXV2IljzasS9e/u2DqpVFinKc=; b=c0D4ccojxLHOwcfe9wg6x7nN+0WnhHeWH5pcuW/A/awuGNyIAJgUjOPLLamscT+ElKKJWPzHF+xG1Xe5iKJNHB+0BS4AEh+DUnrQQOgQ61EmhDPM5Ie2F9YMlsMeJYuTex0ylEb79w3moAJYrg/xAmHWImfcmv6701AhBwOytDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=CSP5KHEJT9Wv6S2BEERxsJDNF6romdwoGcpMZpsqZbSpI/orLqaFgl+/iC7bjqbrV66MIOdkgvwOTmSRptwemXoUrR5dEDZ6SDdV3DPSTnKEAvLsXW8RO3JKICS+lD4f+T820DSQf5khegUk6mXH39oJewYP9Xp/QFWWWkzoXSw= Received: by 10.114.112.1 with SMTP id k1mr1562910wac.24.1200312862315; Mon, 14 Jan 2008 04:14:22 -0800 (PST) Received: by 10.114.182.10 with HTTP; Mon, 14 Jan 2008 04:14:22 -0800 (PST) Message-ID: Date: Mon, 14 Jan 2008 17:44:22 +0530 From: "Gopala Krishna" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Question related to XFS sync , especially fsync Subject: Question related to XFS sync , especially fsync MIME-Version: 1.0 X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.181] X-Barracuda-Start-Time: 1200312863 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.08 X-Barracuda-Spam-Status: No, SCORE=-1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2514 X-archive-position: 14115 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gopalakrishna.n.m@gmail.com Precedence: bulk X-list: xfs Hi, I am seeing some strange problem with XFS and would like to know the expected behavior and if it is faulty is there any patches to resolve the problem. Problem: ====== Basically I am extracting metadata information for a given file by reading the inode structure from the particular disk offset (based on it's position calculated by published inode structure and super block structure information). Before reading the metada data information from the disk, I am calling fsync (I used to call sync, but later I changed to fsync, since sync is not guranteed to flush all meta data) to ensure all metadata related to file is flushed to disk. Later I am reading particular disk offset as per calculation. I am getting XFS magic field properly after mapping to XFs inode structure. However I am not getting dimode properly in some cases (not all cases) and it shows 00000 even for regular file and directory. It is happening only when I copy new file to XFS. But, when I unmount the file system and remount it, everything goes fine and I could get all expected meta data information and proper value for dimode (in the inode structure which indicates the type of the file, i.e regular directory etc.) . Once I mount it back and later even if I remove the same file and copy it back to XFS and then run my utility program, I could read mode information properly. But If I copy different file, again I could not get dimode properly. I have to unmount and remount to get the mode properly to make my utility program to display information properly. Once it starts getting proper mode value, it continues. So I am suspecting, even after calling fsync (which says it would block untill it flushes metadata information to disk ), is not really flushing. So only during unmount, it flushes metadata and hence I could get dimode properly. since after remounting , by reading metadata information , I could get mode properly and differentiate directory or regular file, and also it is filling magic etc. properly, I feel the data I am reading is right and that I could compare with stat system call and ls commands. If I am doing something wrong and no problem with XFS, then I should not get mode field properly even after unmount/remount operation. Is there any problem with XFS fsync? Why dimode is getting updated only during unmount? why not when I call fsync? Because fsync says it has to flush all meta dat to disk before existing. Please let me know your feedback. [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Jan 14 04:24:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 04:24:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0ECOAR1026029 for ; Mon, 14 Jan 2008 04:24:12 -0800 X-ASG-Debug-ID: 1200313467-652d006d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0B7E911CB35E for ; Mon, 14 Jan 2008 04:24:27 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by cuda.sgi.com with ESMTP id lszGxFExEGC15GBX for ; Mon, 14 Jan 2008 04:24:27 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so3891749waf.18 for ; Mon, 14 Jan 2008 04:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=/6UNSo5GlAFtr8IH2JVmy8a5xYjQ7sdeAlxMIKdmB8o=; b=LPuQ0PVSyNfy7p6jhs6zNezAkFgB3BCLJLwbEH/JvEzqTT51teZ2qgUol3sy/ab5Ud2CfT6FuDPn+5AGbP+Ww6/D9n29HQ2/60KQ7ctzkzsfS3Oal0KOQnNYoIIAlj/HVAK4ZyBj+8zRlas51jybw6uMcR9diHx1C9ugMdtwoc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=xdEFZeTXSUgS9uTmxb+PWM+pffXddq+vs7O9muhBDulBR9/0l9cqHQJgyhBb/zSlii0s+6eoK7Ti7jt4m7xLlGX6b8mSHV6QJJx00MPLzfvvMeKVQov+DHwq9EgPGrfuVmQWoGTWUFwdXLGxyo0FzXjSiHlVtvUzelr/9Tavh+A= Received: by 10.114.77.1 with SMTP id z1mr1843846waa.56.1200313466878; Mon, 14 Jan 2008 04:24:26 -0800 (PST) Received: by 10.114.182.10 with HTTP; Mon, 14 Jan 2008 04:24:26 -0800 (PST) Message-ID: Date: Mon, 14 Jan 2008 17:54:26 +0530 From: "Gopala Krishna" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync In-Reply-To: MIME-Version: 1.0 References: X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.183] X-Barracuda-Start-Time: 1200313468 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2919 X-archive-position: 14116 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gopalakrishna.n.m@gmail.com Precedence: bulk X-list: xfs Hi, My system information: -bash-3.00# uname -a Linux XXXXX #1 SMP Thu May 17 14:00:09 UTC 2007 ia64 ia64 ia64 GNU/Linux -bash-3.00# cat /etc/issue Welcome to SUSE Linux Enterprise Server 10 SP1 (ia64) - Kernel \r (\l). Thanks, Gopal. On 1/14/08, Gopala Krishna wrote: > > Hi, > I am seeing some strange problem with XFS and would like to know the > expected behavior and if it is faulty is there any patches to resolve the > problem. > > Problem: > ====== > Basically I am extracting metadata information for a given file by reading > the inode structure from the particular disk offset (based on it's position > calculated by published inode structure and super block structure > information). Before reading the metada data information from the disk, I > am calling fsync (I used to call sync, but later I changed to fsync, since > sync is not guranteed to flush all meta data) to ensure all metadata > related to file is flushed to disk. Later I am reading particular disk > offset as per calculation. I am getting XFS magic field properly after > mapping to XFs inode structure. However I am not getting dimode properly in > some cases (not all cases) and it shows 00000 even for regular file and > directory. > > It is happening only when I copy new file to XFS. But, when I unmount the > file system and remount it, everything goes fine and I could get all > expected meta data information and proper value for dimode (in the inode > structure which indicates the type of the file, i.e regular directory > etc.) . > > Once I mount it back and later even if I remove the same file and copy it > back to XFS and then run my utility program, I could read mode information > properly. But If I copy different file, again I could not get dimode > properly. I have to unmount and remount to get the mode properly to make my > utility program to display information properly. Once it starts getting > proper mode value, it continues. > > So I am suspecting, even after calling fsync (which says it would block > untill it flushes metadata information to disk ), is not really flushing. So > only during unmount, it flushes metadata and hence I could get dimode > properly. since after remounting , by reading metadata information , I could > get mode properly and differentiate directory or regular file, and also it > is filling magic etc. properly, I feel the data I am reading is right and > that I could compare with stat system call and ls commands. > > If I am doing something wrong and no problem with XFS, then I should not > get mode field properly even after unmount/remount operation. > > Is there any problem with XFS fsync? Why dimode is getting updated only > during unmount? why not when I call fsync? Because fsync says it has to > flush all meta dat to disk before existing. > > Please let me know your feedback. > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Jan 14 04:32:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 04:32:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0ECWEts026808 for ; Mon, 14 Jan 2008 04:32:16 -0800 X-ASG-Debug-ID: 1200313951-2ed202370000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A252A11CB363 for ; Mon, 14 Jan 2008 04:32:31 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by cuda.sgi.com with ESMTP id GATW0yIPbhqNQZmB for ; Mon, 14 Jan 2008 04:32:31 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so3895946waf.18 for ; Mon, 14 Jan 2008 04:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=C6oR7s7/ZJORwbHhhTuXUDtVTTGMvzR9PefSqsTowLY=; b=I6b9x0XBS1eAAUbKon5uR/+/5uJOXviOzI4YYiur36H3LQytk8teorGSh88qKKCKCa+7Momy8ML/iTj03YmPlDj0nvgTO3jX+La37jYKTWXbqlZ3vCNWa0iDVagu2zSXwsA8IwU4I213zfDCleC3QtXPJ9aic1o8c5xr6QbSKww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=RWaC/xJpezozUj4Cfw1oz9r23GKjG0CxQTE1ZwkT/RkfLM33zSPjx8a92VfkyM3NM6H7HyYGMMANdhYV8oVaK/YheKT7GVExR/RjJAVNC881rSgDU3zQes8M+cbSrBtNjjrm8Mt3woY7m7hnzU2TR49OtSVGy+cXD2RMBtOzM74= Received: by 10.114.151.13 with SMTP id y13mr1954586wad.60.1200313550262; Mon, 14 Jan 2008 04:25:50 -0800 (PST) Received: by 10.114.182.10 with HTTP; Mon, 14 Jan 2008 04:25:50 -0800 (PST) Message-ID: Date: Mon, 14 Jan 2008 17:55:50 +0530 From: "Gopala Krishna" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync In-Reply-To: MIME-Version: 1.0 References: X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.183] X-Barracuda-Start-Time: 1200313951 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 3217 X-archive-position: 14117 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gopalakrishna.n.m@gmail.com Precedence: bulk X-list: xfs One more information: XFS is not a root file system , but EXT3 is a root file system. Thanks, Gopal. On 1/14/08, Gopala Krishna wrote: > > Hi, > My system information: > -bash-3.00# uname -a > Linux XXXXX #1 SMP Thu May 17 14:00:09 UTC 2007 ia64 ia64 ia64 > GNU/Linux > > -bash-3.00# cat /etc/issue > Welcome to SUSE Linux Enterprise Server 10 SP1 (ia64) - Kernel \r (\l). > > Thanks, > Gopal. > > On 1/14/08, Gopala Krishna wrote: > > > > Hi, > > I am seeing some strange problem with XFS and would like to know the > > expected behavior and if it is faulty is there any patches to resolve the > > problem. > > > > Problem: > > ====== > > Basically I am extracting metadata information for a given file by > > reading the inode structure from the particular disk offset (based on > > it's position calculated by published inode structure and super block > > structure information). Before reading the metada data information from the > > disk, I am calling fsync (I used to call sync, but later I changed to fsync, > > since sync is not guranteed to flush all meta data) to ensure all metadata > > related to file is flushed to disk. Later I am reading particular disk > > offset as per calculation. I am getting XFS magic field properly after > > mapping to XFs inode structure. However I am not getting dimode properly in > > some cases (not all cases) and it shows 00000 even for regular file and > > directory. > > > > It is happening only when I copy new file to XFS. But, when I unmount > > the file system and remount it, everything goes fine and I could get all > > expected meta data information and proper value for dimode (in the inode > > structure which indicates the type of the file, i.e regular directory > > etc.) . > > > > Once I mount it back and later even if I remove the same file and copy > > it back to XFS and then run my utility program, I could read mode > > information properly. But If I copy different file, again I could not get > > dimode properly. I have to unmount and remount to get the mode properly to > > make my utility program to display information properly. Once it starts > > getting proper mode value, it continues. > > > > So I am suspecting, even after calling fsync (which says it would block > > untill it flushes metadata information to disk ), is not really flushing. So > > only during unmount, it flushes metadata and hence I could get dimode > > properly. since after remounting , by reading metadata information , I could > > get mode properly and differentiate directory or regular file, and also it > > is filling magic etc. properly, I feel the data I am reading is right and > > that I could compare with stat system call and ls commands. > > > > If I am doing something wrong and no problem with XFS, then I should not > > get mode field properly even after unmount/remount operation. > > > > Is there any problem with XFS fsync? Why dimode is getting updated only > > during unmount? why not when I call fsync? Because fsync says it has to > > flush all meta dat to disk before existing. > > > > Please let me know your feedback. > > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Jan 14 05:23:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 05:23:39 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.4 required=5.0 tests=BAYES_50,HTML_MESSAGE, MIME_QP_LONG_LINE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0EDNWcw031023 for ; Mon, 14 Jan 2008 05:23:35 -0800 X-ASG-Debug-ID: 1200317027-193f00210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from imo-m20.mx.aol.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60CA7517774 for ; Mon, 14 Jan 2008 05:23:47 -0800 (PST) Received: from imo-m20.mx.aol.com (imo-m20.mx.aol.com [64.12.137.1]) by cuda.sgi.com with ESMTP id GNnzXCEHvkgUxIV8 for ; Mon, 14 Jan 2008 05:23:47 -0800 (PST) Received: from AndrewL733@aol.com by imo-m20.mx.aol.com (mail_out_v38_r9.3.) id 4.c1d.2dedc8d5 (37120) for ; Mon, 14 Jan 2008 08:23:44 -0500 (EST) Received: from WEBMAIL-DG08 (webmail-dg08.sim.aol.com [205.188.171.72]) by cia-ma01.mx.aol.com (v121.4) with ESMTP id MAILCIAMA016-9100478b6260301; Mon, 14 Jan 2008 08:23:44 -0500 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Optimal mkfs settings for md RAID0 over 2x3ware RAIDS Subject: Optimal mkfs settings for md RAID0 over 2x3ware RAIDS Date: Mon, 14 Jan 2008 08:23:44 -0500 X-MB-Message-Source: WebUI X-AOL-IP: 207.180.154.47 X-MB-Message-Type: User MIME-Version: 1.0 From: andrewl733@aol.com X-Mailer: AOL Webmail 33706-STANDARD Received: from 207.180.154.47 by WEBMAIL-DG08.sysops.aol.com (205.188.171.72) with HTTP (WebMailUI); Mon, 14 Jan 2008 08:23:44 -0500 Message-Id: <8CA24C7D24953CD-93C-29C2@WEBMAIL-DG08.sysops.aol.com> X-Barracuda-Connect: imo-m20.mx.aol.com[64.12.137.1] X-Barracuda-Start-Time: 1200317030 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.95 X-Barracuda-Spam-Status: No, SCORE=0.95 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_SC0_SA085b, HTML_MESSAGE, NO_REAL_NAME, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.40 BSF_SC0_SA085b URI: Custom Rule SA085b 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1234 X-archive-position: 14118 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andrewl733@aol.com Precedence: bulk X-list: xfs Hello XFS list, I am trying to figure out the optimal mkfs settings for a large array (i.e.= , 18 TB) consisting of 2 or 4 PHYSICAL 3ware RAID-5 arrays striped together= with Linux software RAID-0. As far as I can tell, this question about comb= ining physical and software RAID has not been asked or answered on the list= .=20 As I understand it, for a SINGLE 12-drive 3ware PHYSICAL Hardware RAID-5 cr= eated with a 3-ware-defined "stripe size" of 64K, the optimal mkfs setting = should be:=20 mkfs.xfs =E2=80=93d=C2=A0 su=3D64k,sw=3D11 /dev/sdX The question is, what is optimal if I stripe together TWO of these Physical= Hardware RAID-5 arrays as a SOFTWARE RAID-0. Casual testing shows striping= together two PHYSICAL RAIDS as sucn can yield a gain in performance of app= roximately 60 percent versus 12-drives. But in order to optimize the RAID-0= device, would the correct mkfs be:=20 mkfs.xfs -d su=3D64k,sw=3D22 /dev/mdX There are now 24 drives minus two for parity. Is the logic correct here?=20 Regards,=20 Andrew ________________________________________________________________________ More new features than ever. Check out the new AOL Mail ! - http://webmail= .aol.com [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Jan 14 06:06:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 06:06:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0EE6I9P002187 for ; Mon, 14 Jan 2008 06:06:19 -0800 X-ASG-Debug-ID: 1200319595-344a00450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 06191517AFB for ; Mon, 14 Jan 2008 06:06:35 -0800 (PST) Received: from mx1.suse.de (mx1.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id PhWCzEe99HVcEuNR for ; Mon, 14 Jan 2008 06:06:35 -0800 (PST) X-ASG-Whitelist: Client Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id DA37A26513; Mon, 14 Jan 2008 15:06:32 +0100 (CET) To: "Gopala Krishna" Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync From: Andi Kleen References: Date: Mon, 14 Jan 2008 15:06:32 +0100 In-Reply-To: (Gopala Krishna's message of "Mon\, 14 Jan 2008 17\:44\:22 +0530") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Barracuda-Connect: mx1.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1200319596 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14119 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs "Gopala Krishna" writes: > ====== > Basically I am extracting metadata information for a given file by reading > the inode structure from the particular disk offset (based on it's position > calculated by published inode structure and super block structure > information). Before reading the metada data information from the disk, I > am calling fsync (I used to call sync, but later I changed to fsync, since > sync is not guranteed to flush all meta data) sync is guaranteed to flush all metadata. But it has other problems like livelocks. to ensure all metadata > related to file is flushed to disk. Later I am reading particular disk > offset as per calculation. I am getting XFS magic field properly after > mapping to XFs inode structure. However I am not getting dimode properly in > some cases (not all cases) and it shows 00000 even for regular file and > directory. I suspect it's flushed to the log only. You could probably write some other metadata until the log is completely full and fsync it, then eventually the first change should be guaranteed to be flushed to the rest of the disk. > If I am doing something wrong Well yes it sounds certainly weird what you're attempting. -Andi From owner-xfs@oss.sgi.com Mon Jan 14 06:30:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 06:31:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0EEUuAL004067 for ; Mon, 14 Jan 2008 06:30:57 -0800 X-ASG-Debug-ID: 1200321072-330700ea0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from orchid.cbk.poznan.pl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DB06311CC064 for ; Mon, 14 Jan 2008 06:31:13 -0800 (PST) Received: from orchid.cbk.poznan.pl (cbk-gw.man.poznan.pl [150.254.210.225]) by cuda.sgi.com with ESMTP id c1JUkHVdW1IRbPQx for ; Mon, 14 Jan 2008 06:31:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by orchid.cbk.poznan.pl (Postfix) with ESMTP id 7E368E49957; Mon, 14 Jan 2008 15:31:11 +0100 (CET) X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new at cbk.poznan.pl Received: from orchid.cbk.poznan.pl ([127.0.0.1]) by localhost (orchid.cbk.poznan.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9UDOTPRJXlF4; Mon, 14 Jan 2008 15:31:10 +0100 (CET) Received: from venus.local.navi.pl (ip-83-238-212-180.netia.com.pl [83.238.212.180]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by orchid.cbk.poznan.pl (Postfix) with ESMTP id 7FE59E4984D; Mon, 14 Jan 2008 15:31:10 +0100 (CET) X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Gopala Krishna Cc: xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Date: Mon, 14 Jan 2008 15:32:32 +0100 Message-Id: <1200321152.10994.13.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: cbk-gw.man.poznan.pl[150.254.210.225] X-Barracuda-Start-Time: 1200321073 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14120 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: xfs On Mon, 2008-01-14 at 17:44 +0530, Gopala Krishna wrote: > So I am suspecting, even after calling fsync (which says it would block > untill it flushes metadata information to disk ), is not really flushing. So > only during unmount, it flushes metadata and hence I could get dimode > properly. since after remounting , by reading metadata information , I could > get mode properly and differentiate directory or regular file, and also it > is filling magic etc. properly, I feel the data I am reading is right and > that I could compare with stat system call and ls commands. The metadata are put in log. So they are on disk. Just not in the place you expect them to find. > > If I am doing something wrong and no problem with XFS, then I should not get > mode field properly even after unmount/remount operation. At remount the log is replayed and the metadata are in the place where you expect them to be. > > Is there any problem with XFS fsync? Why dimode is getting updated only > during unmount? why not when I call fsync? Because fsync says it has to > flush all meta dat to disk before existing. And it does. It is not XFS problem. It is your problem ;) BTW, the GRUB does similiar thing. And many people reported problems about it. Regards, Olaf From owner-xfs@oss.sgi.com Mon Jan 14 06:42:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 06:43:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,MISSING_MIMEOLE autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0EEgvGZ005222 for ; Mon, 14 Jan 2008 06:42:58 -0800 X-ASG-Debug-ID: 1200321794-330701060000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from enyo.dsw2k3.info (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8566511CC1A7 for ; Mon, 14 Jan 2008 06:43:15 -0800 (PST) Received: from enyo.dsw2k3.info (enyo.dsw2k3.info [195.71.86.239]) by cuda.sgi.com with ESMTP id iKQgFKdK6yKO09D7 for ; Mon, 14 Jan 2008 06:43:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by enyo.dsw2k3.info (Postfix) with ESMTP id 0E8342BEA7; Mon, 14 Jan 2008 15:43:13 +0100 (CET) X-Virus-Scanned: ClamAV 0.91.2/5482/Sun Jan 13 13:43:51 2008 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at enyo.dsw2k3.info Received: from enyo.dsw2k3.info ([127.0.0.1]) by localhost (enyo.dsw2k3.info [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MF+KORdsxO0C; Mon, 14 Jan 2008 15:43:10 +0100 (CET) Received: from citd.de (p4FC4D3E2.dip.t-dialin.net [79.196.211.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by enyo.dsw2k3.info (Postfix) with ESMTP id DDCBD2BEA3; Mon, 14 Jan 2008 15:43:09 +0100 (CET) Date: Mon, 14 Jan 2008 15:43:06 +0100 From: Matthias Schniedermeyer To: Gopala Krishna Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: ***** SUSPECTED SPAM ***** Re: Question related to XFS sync , especially fsync Message-ID: <20080114144306.GA4672@citd.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) X-Barracuda-Connect: enyo.dsw2k3.info[195.71.86.239] X-Barracuda-Start-Time: 1200321795 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-ASG-Tag: HEADER (^X-Barracuda-Connect: .*\.info\[.*) X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39507 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Priority: 5 (Lowest) X-MSMail-Priority: Low Importance: Low X-Barracuda-Spam-Flag: YES X-Virus-Status: Clean X-archive-position: 14121 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ms@citd.de Precedence: bulk X-list: xfs On 14.01.2008 17:44, Gopala Krishna wrote: > Hi, > I am seeing some strange problem with XFS and would like to know the > expected behavior and if it is faulty is there any patches to resolve the > problem. > > Problem: > ====== ... The man-page "xfs_freeze" at least reads like it does what you want, i.e. it flushes everything(tm). Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. From owner-xfs@oss.sgi.com Mon Jan 14 09:37:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 09:37:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0EHbRUq021176 for ; Mon, 14 Jan 2008 09:37:31 -0800 X-ASG-Debug-ID: 1200332262-193f024a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 692A351918F for ; Mon, 14 Jan 2008 09:37:43 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 2WpWnjSg9CbfbWQU for ; Mon, 14 Jan 2008 09:37:43 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m0EHbbF3014300 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 14 Jan 2008 18:37:37 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m0EHbaBg014298 for xfs@oss.sgi.com; Mon, 14 Jan 2008 18:37:36 +0100 Date: Mon, 14 Jan 2008 18:37:36 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] fix XFSQA #184 for multiple invocations Subject: [PATCH] fix XFSQA #184 for multiple invocations Message-ID: <20080114173736.GA14234@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1200332265 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39509 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14122 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Make sure the device node is removed before creating it to allow running the testcase multiple times without recreating the filesystem. Signed-off-by: Christoph Hellwig Index: xfstests/184 =================================================================== RCS file: /cvs/xfs-cmds/xfstests/184,v retrieving revision 1.1 diff -u -p -r1.1 184 --- xfstests/184 19 Dec 2007 05:14:33 -0000 1.1 +++ xfstests/184 12 Jan 2008 13:57:26 -0000 @@ -35,6 +35,7 @@ _supported_os IRIX Linux _setup_testdir +rm -f $testdir/null mknod $testdir/null c 1 3 chmod 666 $testdir/null echo fred > $testdir/null From owner-xfs@oss.sgi.com Mon Jan 14 10:01:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 10:01:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0EI1qBF023049 for ; Mon, 14 Jan 2008 10:01:53 -0800 X-ASG-Debug-ID: 1200333730-3463025e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp124.sbc.mail.sp1.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 87933519480 for ; Mon, 14 Jan 2008 10:02:10 -0800 (PST) Received: from smtp124.sbc.mail.sp1.yahoo.com (smtp124.sbc.mail.sp1.yahoo.com [69.147.64.97]) by cuda.sgi.com with SMTP id 1hIQGV53xgnC0IFF for ; Mon, 14 Jan 2008 10:02:10 -0800 (PST) Received: (qmail 75333 invoked from network); 14 Jan 2008 17:55:30 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 14 Jan 2008 17:55:30 -0000 X-YMail-OSG: t1FDUcwVM1lPutFGiqBoCP5y6y6CmEueaCaYRdv3YArtyzZPL8XLacUGnjgUv5Wf5RK7SPVQfQ-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id C03712839783; Mon, 14 Jan 2008 09:55:53 -0800 (PST) Date: Mon, 14 Jan 2008 09:55:53 -0800 From: Chris Wedgwood To: Gopala Krishna Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync Message-ID: <20080114175553.GA3711@puku.stupidest.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Barracuda-Connect: smtp124.sbc.mail.sp1.yahoo.com[69.147.64.97] X-Barracuda-Start-Time: 1200333730 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39510 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14123 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs On Mon, Jan 14, 2008 at 05:44:22PM +0530, Gopala Krishna wrote: > Is there any problem with XFS fsync? Why dimode is getting updated > only during unmount? why not when I call fsync? Because fsync says > it has to flush all meta dat to disk before existing. it's probably in the log if you must poke about under the fs like this, try doing freeze/unfreeze (this is what i suggested to the grub people years ago, but i'm not sure it ever made it upstream) From owner-xfs@oss.sgi.com Mon Jan 14 10:05:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 10:05:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0EI5ZF2023586 for ; Mon, 14 Jan 2008 10:05:36 -0800 X-ASG-Debug-ID: 1200333952-3182015b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail3.key-systems.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id DF64C5194D9 for ; Mon, 14 Jan 2008 10:05:53 -0800 (PST) Received: from mail3.key-systems.net (mail3.key-systems.net [81.3.43.213]) by cuda.sgi.com with SMTP id YL9yS3c5tSVJ3fFC for ; Mon, 14 Jan 2008 10:05:53 -0800 (PST) Received: (qmail 27606 invoked from network); 14 Jan 2008 18:05:13 -0000 Received: from ppp-62-245-211-18.dynamic.mnet-online.de (HELO [62.245.211.18]) (62.245.211.18) by mail3.key-systems.net (qpsmtpd/0.31.1) with ESMTP; Mon, 14 Jan 2008 18:05:13 +0000 X-ASG-Orig-Subj: binary NULL errors Subject: binary NULL errors From: Christoph Anton Mitterer To: xfs@oss.sgi.com Content-Type: text/plain Date: Mon, 14 Jan 2008 19:05:49 +0100 Message-Id: <1200333949.3145.33.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mail3.key-systems.net[81.3.43.213] X-Barracuda-Start-Time: 1200333953 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39510 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14124 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: calestyo@scientia.net Precedence: bulk X-list: xfs Hi. I've got some questions about using XFS. I've already used it as for all my discs about one or two years ago, but then I've suffered several times from the binary NULLs "bug", that happened when the system crashed or had a power loss. I've lost more than one open files (like all my bookmarks in Firefox) and thus I've switched back to ext3 In the FAQ at http://oss.sgi.com/projects/xfs/faq.html it says: Update: This issue has been addressed with a CVS fix on the 29th March 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1. What does this exactly mean and what has been fixed/addressed? Is XFS now similar to ext3 and I won't see those binary NULLs stuff again? What happens now in case of a powerloss? Does XFS still make heavy use of caching techniques? Best wishes, Chris, From owner-xfs@oss.sgi.com Mon Jan 14 14:42:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 14:42:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0EMgaQ4029308 for ; Mon, 14 Jan 2008 14:42:40 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08303; Tue, 15 Jan 2008 09:42:49 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0EMglLF25207878; Tue, 15 Jan 2008 09:42:48 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0EMgjfK25215776; Tue, 15 Jan 2008 09:42:45 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 15 Jan 2008 09:42:45 +1100 From: David Chinner To: Gopala Krishna Cc: xfs@oss.sgi.com Subject: Re: Question related to XFS sync , especially fsync Message-ID: <20080114224245.GT155259@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14125 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jan 14, 2008 at 05:44:22PM +0530, Gopala Krishna wrote: > Hi, > I am seeing some strange problem with XFS and would like to know the > expected behavior and if it is faulty is there any patches to resolve the > problem. > > Problem: > ====== > Basically I am extracting metadata information for a given file by reading > the inode structure from the particular disk offset (based on it's position > calculated by published inode structure and super block structure > information). Before reading the metada data information from the disk, I > am calling fsync (I used to call sync, but later I changed to fsync, since > sync is not guranteed to flush all meta data) to ensure all metadata > related to file is flushed to disk. Later I am reading particular disk > offset as per calculation. I am getting XFS magic field properly after > mapping to XFs inode structure. However I am not getting dimode properly in > some cases (not all cases) and it shows 00000 even for regular file and > directory. How are you finding and reading the inode off disk? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jan 14 14:55:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 14:55:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0EMth5e030814 for ; Mon, 14 Jan 2008 14:55:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08745; Tue, 15 Jan 2008 09:55:56 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0EMtsLF25204375; Tue, 15 Jan 2008 09:55:55 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0EMtqem25218084; Tue, 15 Jan 2008 09:55:52 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 15 Jan 2008 09:55:52 +1100 From: David Chinner To: andrewl733@aol.com Cc: xfs@oss.sgi.com Subject: Re: Optimal mkfs settings for md RAID0 over 2x3ware RAIDS Message-ID: <20080114225552.GU155259@sgi.com> References: <8CA24C7D24953CD-93C-29C2@WEBMAIL-DG08.sysops.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CA24C7D24953CD-93C-29C2@WEBMAIL-DG08.sysops.aol.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14126 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jan 14, 2008 at 08:23:44AM -0500, andrewl733@aol.com wrote: > Hello XFS list, > > I am trying to figure out the optimal mkfs settings for a large > array (i.e., 18 TB) consisting of 2 or 4 PHYSICAL 3ware RAID-5 > arrays striped together with Linux software RAID-0. As far as I > can tell, this question about combining physical and software RAID > has not been asked or answered on the list. > As I understand it, for a SINGLE 12-drive 3ware PHYSICAL Hardware > RAID-5 created with a 3-ware-defined "stripe size" of 64K, the > optimal mkfs setting should be: . > > mkfs.xfs -d su=64k,sw=11 /dev/sdX > > The question is, what is optimal if I stripe together TWO of these > Physical Hardware RAID-5 arrays as a SOFTWARE RAID-0. Casual > testing shows striping together two PHYSICAL RAIDS as sucn can > yield a gain in performance of approximately 60 percent versus > 12-drives. But in order to optimize the RAID-0 device, would the > correct mkfs be: > > mkfs.xfs -d su=64k,sw=22 /dev/mdX > > There are now 24 drives minus two for parity. Is the logic correct here? Depends on your workload and file mix. For lots of small files, the above will work fine. For maximum bandwidth, it will suck. For maximum bandwidth you want XFS to align to the start of a RAID5 lun and do full RAID5 stripe width allocations so that large allocations do not partially overlap RAID5 luns. i.e. with what you suggested, an allocation of 22x64k (full filesystem stripe width) will only be aligned to the underlying hardware in 2 of the possible 22 places it could be allocated with a 64k alignment. in the other 20 cases, you'll get one full RAID5 write to one lun, and two sets of partial RMW cycles to the other lun because they are not full RAID5 stripe writes. That will be slow. With su=11*64k,sw=2, a 22x64k allocation will always be aligned to the underlying geometry (until you start to run out of space) and hence both luns will do a full RAID5 stripe write and it will be fast. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jan 14 15:17:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 15:17:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0ENHfb2000685 for ; Mon, 14 Jan 2008 15:17:44 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA09501; Tue, 15 Jan 2008 10:17:54 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0ENHrLF24274454; Tue, 15 Jan 2008 10:17:53 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0ENHpoS25220828; Tue, 15 Jan 2008 10:17:51 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 15 Jan 2008 10:17:51 +1100 From: David Chinner To: Christoph Anton Mitterer Cc: xfs@oss.sgi.com Subject: Re: binary NULL errors Message-ID: <20080114231751.GV155259@sgi.com> References: <1200333949.3145.33.camel@fermat.scientia.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1200333949.3145.33.camel@fermat.scientia.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14127 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Jan 14, 2008 at 07:05:49PM +0100, Christoph Anton Mitterer wrote: > In the FAQ at http://oss.sgi.com/projects/xfs/faq.html it says: > Update: This issue has been addressed with a CVS fix on the 29th March > 2007 and merged into mainline on 8th May 2007 for 2.6.22-rc1. > > What does this exactly mean and what has been fixed/addressed? It means exactly what it says - that the problem has been fixed if you use 2.6.22 or more recent. If you want details, start looking here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ba87ea699ebd9dd577bf055ebc4a98200e337542 > Is XFS now similar to ext3 and I won't see those binary NULLs stuff > again? Yes, It will behave the same as ext3 - either you'll have a good file or you'll see a zero length file (because the application doesn't overwrite safely). > What happens now in case of a powerloss? Same thing as always happens on power loss - you lose whatever is in memory. We're just more careful about how we update stuff on disk now. > Does XFS still make heavy use > of caching techniques? Yes, just like every other linux filesystem ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jan 14 19:02:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 14 Jan 2008 19:02:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, J_CHICKENPOX_43,MISSING_MIMEOLE,RCVD_IN_PSBL autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0F328Hw017814 for ; Mon, 14 Jan 2008 19:02:11 -0800 X-ASG-Debug-ID: 1200366144-7ddf01b50002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from imo-m12.mail.aol.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9D3EC51C767 for ; Mon, 14 Jan 2008 19:02:25 -0800 (PST) Received: from imo-m12.mail.aol.com (imo-m12.mx.aol.com [64.12.143.100]) by cuda.sgi.com with ESMTP id k7YRS6ZvtCxmE1va for ; Mon, 14 Jan 2008 19:02:25 -0800 (PST) X-ASG-RBL-Restriction: psbl.surriel.com Received: from AndrewL733@aol.com by imo-m12.mx.aol.com (mail_out_v38_r9.3.) id 5.ce5.25f90ac6 (37032); Mon, 14 Jan 2008 22:02:16 -0500 (EST) Received: from WEBMAIL-MC03 (webmail-mc03.webmail.aol.com [64.12.170.80]) by cia-db02.mx.aol.com (v121.4) with ESMTP id MAILCIADB022-90a8478c223726a; Mon, 14 Jan 2008 22:02:15 -0500 References: <8CA24C7D24953CD-93C-29C2@WEBMAIL-DG08.sysops.aol.com> <20080114225552.GU155259@sgi.com> To: dgc@sgi.com X-ASG-Orig-Subj: Re: Optimal mkfs settings for md RAID0 over 2x3ware RAIDS Subject: ***** SUSPECTED SPAM ***** Re: Optimal mkfs settings for md RAID0 over 2x3ware RAIDS Date: Mon, 14 Jan 2008 22:02:16 -0500 X-AOL-IP: 207.180.154.47 In-Reply-To: <20080114225552.GU155259@sgi.com> X-MB-Message-Source: WebUI Received: from 207.180.154.47 by WEBMAIL-MC03.sysops.aol.com (64.12.170.80) with HTTP (WebMailUI); Mon, 14 Jan 2008 22:02:16 -0500 MIME-Version: 1.0 From: andrewl733@aol.com X-MB-Message-Type: User X-Mailer: AOL Webmail 33706-STANDARD Cc: xfs@oss.sgi.com Message-Id: <8CA253A2B251FC3-F4C-1FFE@WEBMAIL-MC03.sysops.aol.com> X-Barracuda-Connect: imo-m12.mx.aol.com[64.12.143.100] X-Barracuda-Start-Time: 1200366146 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-ASG-Tag: RBL (psbl.surriel.com ) X-Barracuda-Spam-Score: -0.79 X-Barracuda-Spam-Status: No, SCORE=-0.79 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_SC0_SA085b, HTML_MESSAGE, MAILTO_TO_SPAM_ADDR, NO_REAL_NAME, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39547 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.40 BSF_SC0_SA085b URI: Custom Rule SA085b 0.00 HTML_MESSAGE BODY: HTML included in message X-Priority: 5 (Lowest) X-MSMail-Priority: Low Importance: Low X-Barracuda-Spam-Flag: YES X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 3111 X-archive-position: 14128 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andrewl733@aol.com Precedence: bulk X-list: xfs Thanks for your speedy reply. Please see a follow up question below. On Mon, Jan 14, 2008 at 08:23:44AM -0500, andrewl733@aol.com wrote: > Hello XFS list, > > I am trying to figure out the optimal mkfs settings for a large > array (i.e., 18 TB) consisting of 2 or 4 PHYSICAL 3ware RAID-5 > arrays striped together with Linux software RAID-0. As far as I > can tell, this question about combining physical and software RAID > has not been asked or answered on the list. > As I understand it, for a SINGLE 12-drive 3ware PHYSICAL Hardware > RAID-5 created with a 3-ware-defined "stripe size" of 64K, the > optimal mkfs setting should be: . > > mkfs.xfs -d su=64k,sw=11 /dev/sdX > > The question is, what is optimal if I stripe together TWO of these > Physical Hardware RAID-5 arrays as a SOFTWARE RAID-0. Casual > testing shows striping together two PHYSICAL RAIDS as sucn can > yield a gain in performance of approximately 60 percent versus > 12-drives. But in order to optimize the RAID-0 device, would the > correct mkfs be: > > mkfs.xfs -d su=64k,sw=22 /dev/mdX > > There are now 24 drives minus two for parity. Is the logic correct here? Depends on your workload and file mix. For lots of small files, the above will work fine. For maximum bandwidth, it will suck. For maximum bandwidth you want XFS to align to the start of a RAID5 lun and do full RAID5 stripe width allocations so that large allocations do not partially overlap RAID5 luns. i.e. with what you suggested, an allocation of 22x64k (full filesystem stripe width) will only be aligned to the underlying hardware in 2 of the possible 22 places it could be allocated with a 64k alignment. in the other 20 cases, you'll get one full RAID5 write to one lun, and two sets of partial RMW cycles to the other lun because they are not full RAID5 stripe writes. That will be slow. With su=11*64k,sw=2, a 22x64k allocation will always be aligned to the underlying geometry (until you start to run out of space) and hence both luns will do a full RAID5 stripe write and it will be fast. In fact, I am testing a 64-drive SAS array today -- 4 x 16-drive RAID-5 arrays striped together with Linux RAID-0.? By your instructions, I should do mkfs as follows: mkfs.xfs -d su=960k,sw=4? /dev/mdX?? where su=15*64k However, I get back the following message: mkfs.xfs:? Specified data stripe unit 1920 is not the same as the volume stripe unit 512 mkfs.xfs:? Specified data stripe width 7680 is not the same as the volume stripe width 2048 The filesystem gets created. What's wrong here? In this case I have chosen to use a Linux md RAID-0 "chunk size" of 256k.? I get a similar message (with different numbers, of course) if I use a "chunk size" of 64k.? Is there an optimal ratio of 3ware "stripe size" to Linux md "chunk size" that also must come into play here? Thanks again in advance. Andrew Cheers, Dave. ________________________________________________________________________ More new features than ever. Check out the new AOL Mail ! - http://webmail.aol.com [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jan 15 05:51:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 05:51:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0FDp46W020069 for ; Tue, 15 Jan 2008 05:51:05 -0800 X-ASG-Debug-ID: 1200405076-3a2c02df0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 00E0711CF87D for ; Tue, 15 Jan 2008 05:51:16 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by cuda.sgi.com with ESMTP id 13ZRrErkzFP2ryeZ for ; Tue, 15 Jan 2008 05:51:16 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so4602580waf.18 for ; Tue, 15 Jan 2008 05:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=OeBJfGKizAzrG0oHGgMrIMcO7PvwiuF4EuTH1JRjwJA=; b=p63cbDlDXsiZFYnML2dvY8whsl65CDk4l98AsQFOARi4fR/Y43LpX3uvlcCu9tpDkjd2JiTFsEQG/h2BBUB6ifbp793ddahCRrnaKtEFA52TfR1NdZDlnGyLiBJ6dJGtM2aHeiMhBGDoTYgrUxwaDd0x+PUeXjRPiHXMhXkkQWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ayhYamzaonH9lOy/AYpydlAl1K+YRYmd6EnNu5yTAjhshWDYeHWvu/91BVCNnhHAhdYTH8vdSoD/z/mHLg3jRs25+zxX1+eMhoAEmYYg5KtD/un5E6O8M/NRfBNH1QNTxVAozOgzHCieif2MpSpsAANdZrAAFNv0UCZeK5WckxA= Received: by 10.115.79.1 with SMTP id g1mr1340688wal.2.1200404652452; Tue, 15 Jan 2008 05:44:12 -0800 (PST) Received: by 10.114.182.4 with HTTP; Tue, 15 Jan 2008 05:44:12 -0800 (PST) Message-ID: Date: Tue, 15 Jan 2008 19:14:12 +0530 From: "Gopala Krishna" To: "David Chinner" , "Chris Wedgwood" , "Matthias Schniedermeyer" , "=?ISO-8859-2?Q?Olaf_Fr=B1czyk?=" , "Andi Kleen" X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync Cc: xfs@oss.sgi.com In-Reply-To: <20080114224245.GT155259@sgi.com> MIME-Version: 1.0 References: <20080114224245.GT155259@sgi.com> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.178] X-Barracuda-Start-Time: 1200405082 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39590 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2311 X-archive-position: 14129 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gopalakrishna.n.m@gmail.com Precedence: bulk X-list: xfs Hi All, Thanks a lot for your response. I never thought it might be in a log and not flushed to disk. Very good clue. >>>It is not XFS problem. It is your problem ;) Good comment. Agreed : -). >>How are you finding and inode off disk I have lot of code getting in to that. To explain that I have to go through that complex part of the code to explain in detail. Basically once we get indoe number for a given file from the available system call, we only depending upon the XFS layout and it's structure. We are reading super block from a particular disk offset and calculating address for inode offset and its address on the disk and reading directly from the disk offset. We are totally depending on XFS on disk layout. To get very much detail , step by step , I have to go through complete code and lot of calculation involved in this process. But it is going fine in most of the cases except when new files are copied and all of you answered for that. Thanks alot for your respopnse. -Gopal. On 1/15/08, David Chinner wrote: > > On Mon, Jan 14, 2008 at 05:44:22PM +0530, Gopala Krishna wrote: > > Hi, > > I am seeing some strange problem with XFS and would like to know the > > expected behavior and if it is faulty is there any patches to resolve > the > > problem. > > > > Problem: > > ====== > > Basically I am extracting metadata information for a given file by > reading > > the inode structure from the particular disk offset (based on > it's position > > calculated by published inode structure and super block structure > > information). Before reading the metada data information from the disk, > I > > am calling fsync (I used to call sync, but later I changed to fsync, > since > > sync is not guranteed to flush all meta data) to ensure all metadata > > related to file is flushed to disk. Later I am reading particular disk > > offset as per calculation. I am getting XFS magic field properly after > > mapping to XFs inode structure. However I am not getting dimode properly > in > > some cases (not all cases) and it shows 00000 even for regular file and > > directory. > > How are you finding and reading the inode off disk? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jan 15 07:17:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 07:18:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0FFHnQu027243 for ; Tue, 15 Jan 2008 07:17:51 -0800 X-ASG-Debug-ID: 1200410286-48f203720000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DEB1851F1A5 for ; Tue, 15 Jan 2008 07:18:06 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id GRCUC4r4kROJbVYs for ; Tue, 15 Jan 2008 07:18:06 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id BA8C618CFB088; Tue, 15 Jan 2008 09:18:03 -0600 (CST) Message-ID: <478CCEAC.9010008@sandeen.net> Date: Tue, 15 Jan 2008 09:18:04 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gopala Krishna CC: David Chinner , Chris Wedgwood , Matthias Schniedermeyer , =?windows-1252?Q?Olaf_Fra=3Bczyk?= , Andi Kleen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync References: <20080114224245.GT155259@sgi.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1200410287 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39596 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14130 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Gopala Krishna wrote: > Hi All, > Thanks a lot for your response. > I never thought it might be in a log and not flushed to disk. > Very good clue. > >>>> It is not XFS problem. It is your problem ;) > Good comment. Agreed : -). > >>> How are you finding and inode off disk > > I have lot of code getting in to that. To explain that I have to go through > that complex part of the code to explain in detail. > > Basically once we get indoe number for a given file from the available > system call, we only depending upon the XFS layout and it's structure. We > are reading super block from a particular disk offset and calculating > address for inode offset and its address on the disk and reading directly > from the disk offset. We are totally depending on XFS on disk layout. Can I ask why you are doing this? :) -Eric From owner-xfs@oss.sgi.com Tue Jan 15 08:47:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 08:48:03 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,FUZZY_CREDIT, MISSING_SUBJECT autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0FGlooF006878 for ; Tue, 15 Jan 2008 08:47:54 -0800 X-ASG-Debug-ID: 1200415684-71f602290001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from Thinpad01 (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 0C568122B53D; Tue, 15 Jan 2008 08:48:05 -0800 (PST) Received: from Thinpad01 ([68.236.66.252]) by cuda.sgi.com with SMTP id Ql62YEnS4j4fAX0k; Tue, 15 Jan 2008 08:48:05 -0800 (PST) From: "Lloyd" To: xfs-master@oss.sgi.com X-Barracuda-Connect: UNKNOWN[68.236.66.252] X-Barracuda-Start-Time: 1200415686 Message-Id: <20080115164805.0C568122B53D@cuda.sgi.com> Date: Tue, 15 Jan 2008 08:48:05 -0800 (PST) X-Barracuda-Bayes: INNOCENT GLOBAL 0.0395 1.0000 -1.7663 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.84 X-Barracuda-Spam-Status: No, SCORE=1.84 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=FUZZY_CREDIT, MISSING_SUBJECT, MSGID_FROM_MTA_ID X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39601 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.70 MSGID_FROM_MTA_ID Message-Id for external message added locally 1.56 FUZZY_CREDIT BODY: Attempt to obfuscate words in spam 1.34 MISSING_SUBJECT Missing Subject: header X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14133 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Lloyd@telus.blackberry.net Precedence: bulk X-list: xfs xfs@oss.sgi.com Subject: Have a 7OO Fico Score in a Month Date: Thu, 17 Jan 2008 16:40:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Email message from: %SENDER% ; Begin the new year right and get rid of negative things on your credlt report for a l5O bucks. Takes about one month to see changes on report. www.scoreflight.net/ has various methods to get yourself a "A" or "B" fico score overnight. See for yourself. Get 5O bucks off total price with promo code elmogo . You can click reply and be taken off of this subscriber list. Thanks for your time and have a good day. From owner-xfs@oss.sgi.com Tue Jan 15 08:47:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 08:48:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,FUZZY_CREDIT, MISSING_SUBJECT autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0FGllD0006865 for ; Tue, 15 Jan 2008 08:47:50 -0800 X-ASG-Debug-ID: 1200415684-71f602290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from Thinpad01 (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 35CE4122B536; Tue, 15 Jan 2008 08:48:04 -0800 (PST) Received: from Thinpad01 ([68.236.66.252]) by cuda.sgi.com with SMTP id 4ER81OWryUjz5qTr; Tue, 15 Jan 2008 08:48:04 -0800 (PST) From: "Kim" To: xfs-master@oss.sgi.com X-Barracuda-Connect: UNKNOWN[68.236.66.252] X-Barracuda-Start-Time: 1200415685 Message-Id: <20080115164804.35CE4122B536@cuda.sgi.com> Date: Tue, 15 Jan 2008 08:48:04 -0800 (PST) X-Barracuda-Bayes: INNOCENT GLOBAL 0.0077 1.0000 -1.9707 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.63 X-Barracuda-Spam-Status: No, SCORE=1.63 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=FUZZY_CREDIT, MISSING_SUBJECT, MSGID_FROM_MTA_ID X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39601 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.70 MSGID_FROM_MTA_ID Message-Id for external message added locally 1.56 FUZZY_CREDIT BODY: Attempt to obfuscate words in spam 1.34 MISSING_SUBJECT Missing Subject: header X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14132 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Kim@aol.com Precedence: bulk X-list: xfs xfs@oss.sgi.com Subject: Remove neg credlt for a hundred fifty Date: Thu, 17 Jan 2008 16:40:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Today's news from %SENDER% - Begin the new year right and get rid of negative things on your credlt report for a l5O bucks. Takes about one month to see changes on report. www.scoreflight.net/ has various methods to get yourself a "A" or "B" fico score overnight. See for yourself. sAVE 5O bucks off total price with promo code elmogo. You can click reply and be take off of this subscriber list. Thanks and have a great day. From owner-xfs@oss.sgi.com Tue Jan 15 08:47:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 08:48:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,FUZZY_CREDIT, MISSING_SUBJECT autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0FGllhQ006863 for ; Tue, 15 Jan 2008 08:47:50 -0800 X-ASG-Debug-ID: 1200415684-71f9022c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from Thinpad01 (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id CAC1F122B535; Tue, 15 Jan 2008 08:48:04 -0800 (PST) Received: from Thinpad01 ([68.236.66.252]) by cuda.sgi.com with SMTP id hvtiCKO7em2odM5I; Tue, 15 Jan 2008 08:48:04 -0800 (PST) From: "Benjamin" To: xfs@oss.sgi.com X-Barracuda-Connect: UNKNOWN[68.236.66.252] X-Barracuda-Start-Time: 1200415684 Message-Id: <20080115164804.CAC1F122B535@cuda.sgi.com> Date: Tue, 15 Jan 2008 08:48:04 -0800 (PST) X-Barracuda-Bayes: INNOCENT GLOBAL 0.0241 1.0000 -1.8647 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.74 X-Barracuda-Spam-Status: No, SCORE=1.74 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=FUZZY_CREDIT, MISSING_SUBJECT, MSGID_FROM_MTA_ID X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39601 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.70 MSGID_FROM_MTA_ID Message-Id for external message added locally 1.56 FUZZY_CREDIT BODY: Attempt to obfuscate words in spam 1.34 MISSING_SUBJECT Missing Subject: header X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14131 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Benjamin@telus.blackberry.net Precedence: bulk X-list: xfs xfs-master@oss.sgi.com Subject: Remove neg credlt for a hundred fifty Date: Thu, 17 Jan 2008 16:40:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Today's news from %SENDER% - Begin the new year right and get rid of negative things on your credlt report for a l5O bucks. Takes about one month to see changes on report. www.scoreflight.net/ has various methods to get yourself a "A" or "B" fico score overnight. See for yourself. sAVE 5O bucks off total price with promo code elmogo. You can click reply and be take off of this subscriber list. Thanks and have a great day. From owner-xfs@oss.sgi.com Tue Jan 15 09:29:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 09:29:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0FHSxNw010216 for ; Tue, 15 Jan 2008 09:29:01 -0800 X-ASG-Debug-ID: 1200418154-7b9100c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C7927520791 for ; Tue, 15 Jan 2008 09:29:14 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id NPJBXl0UCYvsDvHW for ; Tue, 15 Jan 2008 09:29:14 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 1572C1C001994; Tue, 15 Jan 2008 12:29:14 -0500 (EST) Date: Tue, 15 Jan 2008 12:29:14 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com X-ASG-Orig-Subj: Proper swidth and sunit for RAID 5 (does it matter)? Subject: Proper swidth and sunit for RAID 5 (does it matter)? Message-ID: User-Agent: Alpine 0.999999 (DEB 847 2007-12-06) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1200418157 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39603 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 06:45:01 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14134 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Dave, What is the proper sunit and swidth for a 64, 256, and 1024 kilobyte chunk size with a 10-disk raid 5? Also, in the majority of benchmarks it does not seem to matter whether the FS is stripe-aligned or not (with SW raid)- does it mainly/only affect HW raid? Current settings (10 disks): # xfs_info /dev/md3 meta-data=/dev/md3 isize=256 agcount=4, agsize=82417536 blks = sectsz=4096 attr=2 data = bsize=4096 blocks=329670144, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=9437184 blocks=0, rtextents=0 Justin. From owner-xfs@oss.sgi.com Tue Jan 15 13:34:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 13:34:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0FLY1x1002663 for ; Tue, 15 Jan 2008 13:34:05 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA12568; Wed, 16 Jan 2008 08:34:14 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0FLYDLF26386408; Wed, 16 Jan 2008 08:34:14 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0FLYBAn26433418; Wed, 16 Jan 2008 08:34:11 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 16 Jan 2008 08:34:10 +1100 From: David Chinner To: Justin Piszcz Cc: xfs@oss.sgi.com Subject: Re: Proper swidth and sunit for RAID 5 (does it matter)? Message-ID: <20080115213410.GM155407@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14135 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Jan 15, 2008 at 12:29:14PM -0500, Justin Piszcz wrote: > Dave, > > What is the proper sunit and swidth for a 64, 256, and 1024 kilobyte chunk > size with a 10-disk raid 5? > > Also, in the majority of benchmarks it does not seem to matter whether the > FS is stripe-aligned or not (with SW raid)- does it mainly/only affect HW > raid? Affects both. If you are doing large I/O, both SW and HW raid will avoid RMW cycles if you can do full stripe writes and that means they go faster. The faster the RAID array, the bigger the difference it will make. If your tests are with small I/O or with a config that can't do I/O large enough for full stripe writes, then you won't see any difference as you're not avoiding RMW cycles. > Current settings (10 disks): > > # xfs_info /dev/md3 > meta-data=/dev/md3 isize=256 agcount=4, agsize=82417536 Why 4 ags? The low number of AGs is an optimisation for single disks, not multi-disk arrays that have much more parallelism and seek capacity available. > blks > = sectsz=4096 attr=2 > data = bsize=4096 blocks=329670144, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 And you don't even have su/sw set here, so XFS won't be doing any alignment optimisation at all. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jan 15 14:24:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 14:24:24 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0FMOI78010797 for ; Tue, 15 Jan 2008 14:24:20 -0800 X-ASG-Debug-ID: 1200435872-1ac401450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BFBFA522B04 for ; Tue, 15 Jan 2008 14:24:32 -0800 (PST) Received: from postoffice.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id pp0bD6ULC8UZuxxt for ; Tue, 15 Jan 2008 14:24:32 -0800 (PST) Received: from edge.scott.net.au (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 5ADCA92D65B; Wed, 16 Jan 2008 09:23:59 +1100 (EST) X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync From: Nathan Scott Reply-To: nscott@aconex.com To: Gopala Krishna Cc: Eric Sandeen , David Chinner , Chris Wedgwood , Matthias Schniedermeyer , "Olaf Fra;czyk" , Andi Kleen , xfs@oss.sgi.com In-Reply-To: <478CCEAC.9010008@sandeen.net> References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> Content-Type: text/plain Organization: Aconex Date: Wed, 16 Jan 2008 09:26:52 +1100 Message-Id: <1200436012.9463.184.camel@edge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1200435876 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39623 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14136 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Tue, 2008-01-15 at 09:18 -0600, Eric Sandeen wrote: > > > I have lot of code getting in to that. To explain that I have to go > through > > that complex part of the code to explain in detail. > > > > Basically once we get indoe number for a given file from the > available > > system call, we only depending upon the XFS layout and it's > structure. We > > are reading super block from a particular disk offset and > calculating > > address for inode offset and its address on the disk and reading > directly > > from the disk offset. We are totally depending on XFS on disk > layout. > > Can I ask why you are doing this? :) > This would be good to know. If you absolutely must use inode numbers instead of path names, you should use the "by-handle" interface (like xfsdump, xfs_fsr, etc) and not use the ondisk structures directly - doing so is always "broken by design" and you'll get little sympathy here for doing so. :) cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jan 15 16:50:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 16:51:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0G0orwD023453 for ; Tue, 15 Jan 2008 16:50:57 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19900; Wed, 16 Jan 2008 11:51:05 +1100 Date: Wed, 16 Jan 2008 11:51:21 +1100 To: "Chandan Talukdar" Subject: Re: [REVIEW] Refactor xfs_repair's process_dinode_int From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <4782B72D.8070208@agami.com> <47833C0F.6070206@agami.com> <478D1899.9080201@agami.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <478D1899.9080201@agami.com> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14137 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 16 Jan 2008 07:33:29 +1100, Chandan Talukdar wrote: > Hi Barry, > > - In process_misc_ino_types(), dino->di_core.di_size is being accessed > without being converted to machine format. The check is being performed > against 0; so, it should be fine. But for better code readability, I > guess it should be accessed through be64_to_cpu(). Yeah... sort of in two-minds about this one. > - In change_dinode_fmt(), it might be worthwhile to add an ASSERT > against someone passing a value greater than 16 bit for 'new_fmt'. Good idea. > - In process_inode_attr_fork(), di_anextents should be accessed using > be16_to_cpu as it is a 16 bit quantity. > > - In process_dinode_int() line 2691, dinoc->di_extsize should be > accessed using be32_to_cpu(). Good pickup on these, thanks :) > - In process_dinode_int(), we should be checking for 'dblkmap' not being > NULL before freeing it. There are a few error conditions which can > cause the control to go to 'clear_bad_out' with dblkmap being NULL. freeing a NULL is valid, from the man page: free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs. >>> If ptr is NULL, no operation is performed. <<< > Thanks, > Chandan From owner-xfs@oss.sgi.com Tue Jan 15 17:03:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 17:03:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63, J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G13CL6024399 for ; Tue, 15 Jan 2008 17:03:12 -0800 X-ASG-Debug-ID: 1200445402-43c700490000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3E7765238F4 for ; Tue, 15 Jan 2008 17:03:22 -0800 (PST) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id ueIrCCXiCRH52zRc for ; Tue, 15 Jan 2008 17:03:22 -0800 (PST) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m0G12uWb020888 for ; Tue, 15 Jan 2008 17:02:56 -0800 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m0G12p2J001913 for ; Tue, 15 Jan 2008 17:02:51 -0800 Received: from [10.123.4.142] ([10.123.4.142]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Jan 2008 17:03:13 -0800 Message-ID: <478D57D1.2000600@agami.com> Date: Tue, 15 Jan 2008 17:03:13 -0800 From: Michael Nishimoto User-Agent: Mail/News 1.5.0.4 (X11/20060629) MIME-Version: 1.0 To: Barry Naujok CC: xfs@oss.sgi.com, xfs-dev , Chandan Talukdar X-ASG-Orig-Subj: Re: [REVIEW] Refactor xfs_repair's process_dinode_int Subject: Re: [REVIEW] Refactor xfs_repair's process_dinode_int References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2008 01:03:13.0922 (UTC) FILETIME=[92038E20:01C857DB] X-Scanned-By: MIMEDefang 2.58 on 192.168.168.13 X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1200445407 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39634 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14138 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miken@agami.com Precedence: bulk X-list: xfs Hi, I'm posting this for Chandan Talukdar because his email address has been booted from the xfs mailing list again. Michael =============================================== - In process_misc_ino_types(), dino->di_core.di_size is being accessed without being converted to machine format. The check is being performed against 0; so, it should be fine. But for better code readability, I guess it should be accessed through be64_to_cpu(). - In change_dinode_fmt(), it might be worthwhile to add an ASSERT against someone passing a value greater than 16 bit for 'new_fmt'. - In process_inode_attr_fork(), di_anextents should be accessed using be16_to_cpu as it is a 16 bit quantity. - In process_dinode_int() line 2691, dinoc->di_extsize should be accessed using be32_to_cpu(). - In process_dinode_int(), we should be checking for 'dblkmap' not being NULL before freeing it. There are a few error conditions which can cause the control to go to 'clear_bad_out' with dblkmap being NULL. Thanks, Chandan Barry Naujok wrote: > Implementing casefold-table checking in xfs_repair, I have to > touch process_dinode_int. It's a horrendous function. The attached > patch hopefully makes it much clearer what it does and removes a > lot of duplicate code when bad inodes are found. There are some > obscure bug fixes too (eg. two places where the inode's di_mode is > updated, but not marked dirty - libxfs would have tossed it). > > The refactoring involved removing unused variables, working out > what various variables actually did and use them appropriately > and break blocks of functionality into separate functions. > > Barry. > > > ------------------------------------------------------------------------ > > > =========================================================================== > xfsprogs/repair/dino_chunks.c > =========================================================================== > > --- a/xfsprogs/repair/dino_chunks.c 2007-11-15 17:24:33.000000000 +1100 > +++ b/xfsprogs/repair/dino_chunks.c 2007-11-14 15:41:03.188152397 +1100 > @@ -593,7 +593,6 @@ process_inode_chunk( > xfs_agino_t agino; > xfs_agblock_t agbno; > int dirty = 0; > - int cleared = 0; > int isa_dir = 0; > int blks_per_cluster; > int cluster_count; > @@ -777,8 +776,7 @@ process_inode_chunk( > > status = process_dinode(mp, dino, agno, agino, > is_inode_free(ino_rec, irec_offset), > - &ino_dirty, &cleared, &is_used, > - ino_discovery, check_dups, > + &ino_dirty, &is_used,ino_discovery, check_dups, > extra_attr_check, &isa_dir, &parent); > > ASSERT(is_used != 3); > > =========================================================================== > xfsprogs/repair/dinode.c > =========================================================================== > > --- a/xfsprogs/repair/dinode.c 2007-11-15 17:24:33.000000000 +1100 > +++ b/xfsprogs/repair/dinode.c 2007-11-15 17:23:49.322691248 +1100 > @@ -58,9 +58,6 @@ calc_attr_offset(xfs_mount_t *mp, xfs_di > case XFS_DINODE_FMT_LOCAL: > offset += INT_GET(dinoc->di_size, ARCH_CONVERT); > break; > - case XFS_DINODE_FMT_UUID: > - offset += sizeof(uuid_t); > - break; > case XFS_DINODE_FMT_EXTENTS: > offset += INT_GET(dinoc->di_nextents, ARCH_CONVERT) * sizeof(xfs_bmbt_rec_32_t); > break; > @@ -1563,8 +1560,11 @@ null_check(char *name, int length) > * bogus > */ > int > -process_symlink(xfs_mount_t *mp, xfs_ino_t lino, xfs_dinode_t *dino, > - blkmap_t *blkmap) > +process_symlink( > + xfs_mount_t *mp, > + xfs_ino_t lino, > + xfs_dinode_t *dino, > + blkmap_t *blkmap) > { > xfs_dfsbno_t fsbno; > xfs_dinode_core_t *dinoc = &dino->di_core; > @@ -1673,8 +1673,7 @@ process_symlink(xfs_mount_t *mp, xfs_ino > * called to process the set of misc inode special inode types > * that have no associated data storage (fifos, pipes, devices, etc.). > */ > -/* ARGSUSED */ > -int > +static int > process_misc_ino_types(xfs_mount_t *mp, > xfs_dinode_t *dino, > xfs_ino_t lino, > @@ -1693,27 +1692,27 @@ process_misc_ino_types(xfs_mount_t *mp, > /* > * must also have a zero size > */ > - if (INT_GET(dino->di_core.di_size, ARCH_CONVERT) != 0) { > + if (dino->di_core.di_size != 0) { > switch (type) { > case XR_INO_CHRDEV: > do_warn(_("size of character device inode %llu != 0 " > "(%lld bytes)\n"), lino, > - INT_GET(dino->di_core.di_size, ARCH_CONVERT)); > + be64_to_cpu(dino->di_core.di_size)); > break; > case XR_INO_BLKDEV: > do_warn(_("size of block device inode %llu != 0 " > "(%lld bytes)\n"), lino, > - INT_GET(dino->di_core.di_size, ARCH_CONVERT)); > + be64_to_cpu(dino->di_core.di_size)); > break; > case XR_INO_SOCK: > do_warn(_("size of socket inode %llu != 0 " > "(%lld bytes)\n"), lino, > - INT_GET(dino->di_core.di_size, ARCH_CONVERT)); > + be64_to_cpu(dino->di_core.di_size)); > break; > case XR_INO_FIFO: > do_warn(_("size of fifo inode %llu != 0 " > "(%lld bytes)\n"), lino, > - INT_GET(dino->di_core.di_size, ARCH_CONVERT)); > + be64_to_cpu(dino->di_core.di_size)); > break; > default: > do_warn(_("Internal error - process_misc_ino_types, " > @@ -1769,712 +1768,393 @@ process_misc_ino_types_blocks(xfs_drfsbn > return (0); > } > > -/* > - * returns 0 if the inode is ok, 1 if the inode is corrupt > - * check_dups can be set to 1 *only* when called by the > - * first pass of the duplicate block checking of phase 4. > - * *dirty is set > 0 if the dinode has been altered and > - * needs to be written out. > - * > - * for detailed, info, look at process_dinode() comments. > - */ > -/* ARGSUSED */ > -int > -process_dinode_int(xfs_mount_t *mp, > - xfs_dinode_t *dino, > - xfs_agnumber_t agno, > - xfs_agino_t ino, > - int was_free, /* 1 if inode is currently free */ > - int *dirty, /* out == > 0 if inode is now dirty */ > - int *cleared, /* out == 1 if inode was cleared */ > - int *used, /* out == 1 if inode is in use */ > - int verify_mode, /* 1 == verify but don't modify inode */ > - int uncertain, /* 1 == inode is uncertain */ > - int ino_discovery, /* 1 == check dirs for unknown inodes */ > - int check_dups, /* 1 == check if inode claims > - * duplicate blocks */ > - int extra_attr_check, /* 1 == do attribute format and value checks */ > - int *isa_dir, /* out == 1 if inode is a directory */ > - xfs_ino_t *parent) /* out -- parent if ino is a dir */ > +static inline int > +dinode_fmt( > + xfs_dinode_core_t *dinoc) > { > - xfs_drfsbno_t totblocks = 0; > - xfs_drfsbno_t atotblocks = 0; > - xfs_dinode_core_t *dinoc; > - char *rstring; > - int type; > - int rtype; > - int do_rt; > - int err; > - int retval = 0; > - __uint64_t nextents; > - __uint64_t anextents; > - xfs_ino_t lino; > - const int is_free = 0; > - const int is_used = 1; > - int repair = 0; > - blkmap_t *ablkmap = NULL; > - blkmap_t *dblkmap = NULL; > - static char okfmts[] = { > - 0, /* free inode */ > - 1 << XFS_DINODE_FMT_DEV, /* FIFO */ > - 1 << XFS_DINODE_FMT_DEV, /* CHR */ > - 0, /* type 3 unused */ > - (1 << XFS_DINODE_FMT_LOCAL) | > - (1 << XFS_DINODE_FMT_EXTENTS) | > - (1 << XFS_DINODE_FMT_BTREE), /* DIR */ > - 0, /* type 5 unused */ > - 1 << XFS_DINODE_FMT_DEV, /* BLK */ > - 0, /* type 7 unused */ > - (1 << XFS_DINODE_FMT_EXTENTS) | > - (1 << XFS_DINODE_FMT_BTREE), /* REG */ > - 0, /* type 9 unused */ > - (1 << XFS_DINODE_FMT_LOCAL) | > - (1 << XFS_DINODE_FMT_EXTENTS), /* LNK */ > - 0, /* type 11 unused */ > - 1 << XFS_DINODE_FMT_DEV, /* SOCK */ > - 0, /* type 13 unused */ > - 1 << XFS_DINODE_FMT_UUID, /* MNT */ > - 0 /* type 15 unused */ > - }; > - > - retval = 0; > - totblocks = atotblocks = 0; > - *dirty = *isa_dir = *cleared = 0; > - *used = is_used; > - type = rtype = XR_INO_UNKNOWN; > - rstring = NULL; > - do_rt = 0; > + return be16_to_cpu(dinoc->di_mode) & S_IFMT; > +} > > - dinoc = &dino->di_core; > - lino = XFS_AGINO_TO_INO(mp, agno, ino); > +static inline void > +change_dinode_fmt( > + xfs_dinode_core_t *dinoc, > + int new_fmt) > +{ > + int mode = be16_to_cpu(dinoc->di_mode); > > - /* > - * if in verify mode, don't modify the inode. > - * > - * if correcting, reset stuff that has known values > - * > - * if in uncertain mode, be silent on errors since we're > - * trying to find out if these are inodes as opposed > - * to assuming that they are. Just return the appropriate > - * return code in that case. > - */ > + mode &= ~S_IFMT; > + mode |= new_fmt; > + dinoc->di_mode = cpu_to_be16(mode); > +} > > - if (INT_GET(dinoc->di_magic, ARCH_CONVERT) != XFS_DINODE_MAGIC) { > - retval++; > - if (!verify_mode) { > - do_warn(_("bad magic number 0x%x on inode %llu, "), > - INT_GET(dinoc->di_magic, ARCH_CONVERT), lino); > +static int > +check_dinode_mode_format( > + xfs_dinode_core_t *dinoc) > +{ > + if ((uchar_t)dinoc->di_format >= XFS_DINODE_FMT_UUID) > + return -1; /* FMT_UUID is not used */ > + > + switch (dinode_fmt(dinoc)) { > + case S_IFIFO: > + case S_IFCHR: > + case S_IFBLK: > + case S_IFSOCK: > + return (dinoc->di_format != XFS_DINODE_FMT_DEV) ? -1 : 0; > + > + case S_IFDIR: > + return (dinoc->di_format < XFS_DINODE_FMT_LOCAL || > + dinoc->di_format > XFS_DINODE_FMT_BTREE) ? -1 : 0; > + > + case S_IFREG: > + return (dinoc->di_format < XFS_DINODE_FMT_EXTENTS || > + dinoc->di_format > XFS_DINODE_FMT_BTREE) ? -1 : 0; > + > + case S_IFLNK: > + return (dinoc->di_format < XFS_DINODE_FMT_LOCAL || > + dinoc->di_format > XFS_DINODE_FMT_EXTENTS) ? -1 : 0; > + > + default: ; > + } > + return 0; /* invalid modes are checked elsewhere */ > +} > + > +/* > + * If inode is a superblock inode, does type check to make sure is it valid. > + * Returns 0 if it's valid, non-zero if it needs to be cleared. > + */ > + > +static int > +process_check_sb_inodes( > + xfs_mount_t *mp, > + xfs_dinode_core_t *dinoc, > + xfs_ino_t lino, > + int *type, > + int *dirty) > +{ > + if (lino == mp->m_sb.sb_rootino) { > + if (*type != XR_INO_DIR) { > + do_warn(_("root inode %llu has bad type 0x%x\n"), > + lino, dinode_fmt(dinoc)); > + *type = XR_INO_DIR; > if (!no_modify) { > - do_warn(_("resetting magic number\n")); > + do_warn(_("resetting to directory\n")); > + change_dinode_fmt(dinoc, S_IFDIR); > *dirty = 1; > - INT_SET(dinoc->di_magic, ARCH_CONVERT, > - XFS_DINODE_MAGIC); > - } else { > - do_warn(_("would reset magic number\n")); > - } > - } else if (!uncertain) { > - do_warn(_("bad magic number 0x%x on inode %llu\n"), > - INT_GET(dinoc->di_magic, ARCH_CONVERT), lino); > + } else > + do_warn(_("would reset to directory\n")); > } > + return 0; > } > - > - if (!XFS_DINODE_GOOD_VERSION(dinoc->di_version) || > - (!fs_inode_nlink && dinoc->di_version > XFS_DINODE_VERSION_1)) { > - retval++; > - if (!verify_mode) { > - do_warn(_("bad version number 0x%x on inode %llu, "), > - dinoc->di_version, lino); > + if (lino == mp->m_sb.sb_uquotino) { > + if (*type != XR_INO_DATA) { > + do_warn(_("user quota inode %llu has bad type 0x%x\n"), > + lino, dinode_fmt(dinoc)); > + mp->m_sb.sb_uquotino = NULLFSINO; > + return 1; > + } > + return 0; > + } > + if (lino == mp->m_sb.sb_gquotino) { > + if (*type != XR_INO_DATA) { > + do_warn(_("group quota inode %llu has bad type 0x%x\n"), > + lino, dinode_fmt(dinoc)); > + mp->m_sb.sb_gquotino = NULLFSINO; > + return 1; > + } > + return 0; > + } > + if (lino == mp->m_sb.sb_rsumino) { > + if (*type != XR_INO_RTSUM) { > + do_warn(_("realtime summary inode %llu has bad type 0x%x, "), > + lino, dinode_fmt(dinoc)); > if (!no_modify) { > - do_warn(_("resetting version number\n")); > + do_warn(_("resetting to regular file\n")); > + change_dinode_fmt(dinoc, S_IFREG); > *dirty = 1; > - dinoc->di_version = (fs_inode_nlink) ? > - XFS_DINODE_VERSION_2 : > - XFS_DINODE_VERSION_1; > } else { > - do_warn(_("would reset version number\n")); > + do_warn(_("would reset to regular file\n")); > } > - } else if (!uncertain) { > - do_warn(_("bad version number 0x%x on inode %llu\n"), > - dinoc->di_version, lino); > } > + if (mp->m_sb.sb_rblocks == 0 && dinoc->di_nextents != 0) { > + do_warn(_("bad # of extents (%u) for realtime summary inode %llu\n"), > + be32_to_cpu(dinoc->di_nextents), lino); > + return 1; > + } > + return 0; > } > - > - /* > - * blow out of here if the inode size is < 0 > - */ > - if (INT_GET(dinoc->di_size, ARCH_CONVERT) < 0) { > - retval++; > - if (!verify_mode) { > - do_warn(_("bad (negative) size %lld on inode %llu\n"), > - INT_GET(dinoc->di_size, ARCH_CONVERT), lino); > + if (lino == mp->m_sb.sb_rbmino) { > + if (*type != XR_INO_RTBITMAP) { > + do_warn(_("realtime bitmap inode %llu has bad type 0x%x, "), > + lino, dinode_fmt(dinoc)); > if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - *cleared = 1; > - } else { > + do_warn(_("resetting to regular file\n")); > + change_dinode_fmt(dinoc, S_IFREG); > *dirty = 1; > - *cleared = 1; > + } else { > + do_warn(_("would reset to regular file\n")); > } > - *used = is_free; > - } else if (!uncertain) { > - do_warn(_("bad (negative) size %lld on inode %llu\n"), > - INT_GET(dinoc->di_size, ARCH_CONVERT), lino); > } > - > - return(1); > + if (mp->m_sb.sb_rblocks == 0 && dinoc->di_nextents != 0) { > + do_warn(_("bad # of extents (%u) for realtime bitmap inode %llu\n"), > + be32_to_cpu(dinoc->di_nextents), lino); > + return 1; > + } > + return 0; > } > + return 0; > +} > > - /* > - * was_free value is not meaningful if we're in verify mode > - */ > - if (!verify_mode && INT_GET(dinoc->di_mode, ARCH_CONVERT) == 0 && was_free == 1) { > - /* > - * easy case, inode free -- inode and map agree, clear > - * it just in case to ensure that format, etc. are > - * set correctly > - */ > - if (!no_modify) { > - err = clear_dinode(mp, dino, lino); > - if (err) { > - *dirty = 1; > - *cleared = 1; > - } > +/* > + * general size/consistency checks: > + * > + * if the size <= size of the data fork, directories must be > + * local inodes unlike regular files which would be extent inodes. > + * all the other mentioned types have to have a zero size value. > + * > + * if the size and format don't match, get out now rather than > + * risk trying to process a non-existent extents or btree > + * type data fork. > + */ > +static int > +process_check_inode_sizes( > + xfs_mount_t *mp, > + xfs_dinode_t *dino, > + xfs_ino_t lino, > + int type) > +{ > + xfs_dinode_core_t *dinoc = &dino->di_core; > + xfs_fsize_t size = be64_to_cpu(dinoc->di_size); > + > + switch (type) { > + > + case XR_INO_DIR: > + if (size <= XFS_DFORK_DSIZE(dino, mp) && > + dinoc->di_format != XFS_DINODE_FMT_LOCAL) { > + do_warn(_("mismatch between format (%d) and size " > + "(%lld) in directory ino %llu\n"), > + dinoc->di_format, size, lino); > + return 1; > } > - *used = is_free; > - return(0); > - } else if (!verify_mode && INT_GET(dinoc->di_mode, ARCH_CONVERT) == 0 && was_free == 0) { > + break; > + > + case XR_INO_SYMLINK: > + if (process_symlink_extlist(mp, lino, dino)) { > + do_warn(_("bad data fork in symlink %llu\n"), lino); > + return 1; > + } > + break; > + > + case XR_INO_CHRDEV: /* fall through to FIFO case ... */ > + case XR_INO_BLKDEV: /* fall through to FIFO case ... */ > + case XR_INO_SOCK: /* fall through to FIFO case ... */ > + case XR_INO_MOUNTPOINT: /* fall through to FIFO case ... */ > + case XR_INO_FIFO: > + if (process_misc_ino_types(mp, dino, lino, type)) > + return 1; > + break; > + > + case XR_INO_RTDATA: > /* > - * the inode looks free but the map says it's in use. > - * clear the inode just to be safe and mark the inode > - * free. > + * if we have no realtime blocks, any inode claiming > + * to be a real-time file is bogus > */ > - do_warn(_("imap claims a free inode %llu is in use, "), lino); > - > - if (!no_modify) { > - do_warn(_("correcting imap and clearing inode\n")); > + if (mp->m_sb.sb_rblocks == 0) { > + do_warn(_("found inode %llu claiming to be a " > + "real-time file\n"), lino); > + return 1; > + } > + break; > > - err = clear_dinode(mp, dino, lino); > - if (err) { > - retval++; > - *dirty = 1; > - *cleared = 1; > - } > - } else { > - do_warn(_("would correct imap and clear inode\n")); > + case XR_INO_RTBITMAP: > + if (size != (__int64_t)mp->m_sb.sb_rbmblocks * > + mp->m_sb.sb_blocksize) { > + do_warn(_("realtime bitmap inode %llu has bad size " > + "%lld (should be %lld)\n"), > + lino, size, (__int64_t) mp->m_sb.sb_rbmblocks * > + mp->m_sb.sb_blocksize); > + return 1; > + } > + break; > > - *dirty = 1; > - *cleared = 1; > + case XR_INO_RTSUM: > + if (size != mp->m_rsumsize) { > + do_warn(_("realtime summary inode %llu has bad size " > + "%lld (should be %d)\n"), > + lino, size, mp->m_rsumsize); > + return 1; > } > + break; > > - *used = is_free; > + default: > + break; > + } > + return 0; > +} > > - return(retval > 0 ? 1 : 0); > +/* > + * check for illegal values of forkoff > + */ > +static int > +process_check_inode_forkoff( > + xfs_mount_t *mp, > + xfs_dinode_core_t *dinoc, > + xfs_ino_t lino) > +{ > + if (dinoc->di_forkoff == 0) > + return 0; > + > + switch (dinoc->di_format) { > + case XFS_DINODE_FMT_DEV: > + if (dinoc->di_forkoff != (roundup(sizeof(xfs_dev_t), 8) >> 3)) { > + do_warn(_("bad attr fork offset %d in dev inode %llu, " > + "should be %d\n"), dinoc->di_forkoff, lino, > + (int)(roundup(sizeof(xfs_dev_t), 8) >> 3)); > + return 1; > + } > + break; > + case XFS_DINODE_FMT_LOCAL: /* fall through ... */ > + case XFS_DINODE_FMT_EXTENTS: /* fall through ... */ > + case XFS_DINODE_FMT_BTREE: > + if (dinoc->di_forkoff >= (XFS_LITINO(mp) >> 3)) { > + do_warn(_("bad attr fork offset %d in inode %llu, " > + "max=%d\n"), dinoc->di_forkoff, lino, > + XFS_LITINO(mp) >> 3); > + return 1; > + } > + break; > + default: > + do_error(_("unexpected inode format %d\n"), dinoc->di_format); > + break; > } > + return 0; > +} > > - /* > - * because of the lack of any write ordering guarantee, it's > - * possible that the core got updated but the forks didn't. > - * so rather than be ambitious (and probably incorrect), > - * if there's an inconsistency, we get conservative and > - * just pitch the file. blow off checking formats of > - * free inodes since technically any format is legal > - * as we reset the inode when we re-use it. > - */ > - if (INT_GET(dinoc->di_mode, ARCH_CONVERT) != 0 && > - ((((INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT) >> 12) > 15) || > - (uchar_t) dinoc->di_format > XFS_DINODE_FMT_UUID || > - (!(okfmts[(INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT) >> 12] & > - (1 << dinoc->di_format))))) { > - /* bad inode format */ > - retval++; > - if (!uncertain) > - do_warn(_("bad inode format in inode %llu\n"), lino); > - if (!verify_mode) { > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > +/* > + * Updates the inodes block and extent counts if they are wrong > + */ > +static int > +process_inode_blocks_and_extents( > + xfs_dinode_core_t *dinoc, > + xfs_drfsbno_t nblocks, > + __uint64_t nextents, > + __uint64_t anextents, > + xfs_ino_t lino, > + int *dirty) > +{ > + if (nblocks != be64_to_cpu(dinoc->di_nblocks)) { > + if (!no_modify) { > + do_warn(_("correcting nblocks for inode %llu, " > + "was %llu - counted %llu\n"), lino, > + be64_to_cpu(dinoc->di_nblocks), nblocks); > + dinoc->di_nblocks = cpu_to_be64(nblocks); > + *dirty = 1; > + } else { > + do_warn(_("bad nblocks %llu for inode %llu, " > + "would reset to %llu\n"), > + be64_to_cpu(dinoc->di_nblocks), lino, nblocks); > } > - *cleared = 1; > - *used = is_free; > + } > > - return(retval > 0 ? 1 : 0); > + if (nextents > MAXEXTNUM) { > + do_warn(_("too many data fork extents (%llu) in inode %llu\n"), > + nextents, lino); > + return 1; > + } > + if (nextents != be32_to_cpu(dinoc->di_nextents)) { > + if (!no_modify) { > + do_warn(_("correcting nextents for inode %llu, " > + "was %d - counted %llu\n"), lino, > + be32_to_cpu(dinoc->di_nextents), nextents); > + dinoc->di_nextents = cpu_to_be32(nextents); > + *dirty = 1; > + } else { > + do_warn(_("bad nextents %d for inode %llu, would reset " > + "to %llu\n"), be32_to_cpu(dinoc->di_nextents), > + lino, nextents); > + } > } > > - if (verify_mode) > - return(retval > 0 ? 1 : 0); > + if (anextents > MAXAEXTNUM) { > + do_warn(_("too many attr fork extents (%llu) in inode %llu\n"), > + anextents, lino); > + return 1; > + } > + if (anextents != be16_to_cpu(dinoc->di_anextents)) { > + if (!no_modify) { > + do_warn(_("correcting anextents for inode %llu, " > + "was %d - counted %llu\n"), lino, > + be16_to_cpu(dinoc->di_anextents), anextents); > + dinoc->di_anextents = cpu_to_be16(anextents); > + *dirty = 1; > + } else { > + do_warn(_("bad anextents %d for inode %llu, would reset" > + " to %llu\n"), be16_to_cpu(dinoc->di_anextents), > + lino, anextents); > + } > + } > + return 0; > +} > > - /* > - * clear the next unlinked field if necessary on a good > - * inode only during phase 4 -- when checking for inodes > - * referencing duplicate blocks. then it's safe because > - * we've done the inode discovery and have found all the inodes > - * we're going to find. check_dups is set to 1 only during > - * phase 4. Ugly. > - */ > - if (check_dups && !no_modify) > - *dirty += clear_dinode_unlinked(mp, dino); > +/* > + * check data fork -- if it's bad, clear the inode > + */ > +static int > +process_inode_data_fork( > + xfs_mount_t *mp, > + xfs_agnumber_t agno, > + xfs_agino_t ino, > + xfs_dinode_t *dino, > + int type, > + int *dirty, > + xfs_drfsbno_t *totblocks, > + __uint64_t *nextents, > + blkmap_t **dblkmap, > + int check_dups) > +{ > + xfs_dinode_core_t *dinoc = &dino->di_core; > + xfs_ino_t lino = XFS_AGINO_TO_INO(mp, agno, ino); > + int err = 0; > > - /* set type and map type info */ > + *nextents = be32_to_cpu(dinoc->di_nextents); > + if (*nextents > be64_to_cpu(dinoc->di_nblocks) || > + *nextents > XFS_MAX_INCORE_EXTENTS) > + *nextents = 1; > + > + if (dinoc->di_format != XFS_DINODE_FMT_LOCAL && type != XR_INO_RTDATA) > + *dblkmap = blkmap_alloc(*nextents); > + *nextents = 0; > > - switch (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT) { > - case S_IFDIR: > - type = XR_INO_DIR; > - *isa_dir = 1; > - break; > - case S_IFREG: > - if (INT_GET(dinoc->di_flags, ARCH_CONVERT) & XFS_DIFLAG_REALTIME) > - type = XR_INO_RTDATA; > - else if (lino == mp->m_sb.sb_rbmino) > - type = XR_INO_RTBITMAP; > - else if (lino == mp->m_sb.sb_rsumino) > - type = XR_INO_RTSUM; > - else > - type = XR_INO_DATA; > - break; > - case S_IFLNK: > - type = XR_INO_SYMLINK; > - break; > - case S_IFCHR: > - type = XR_INO_CHRDEV; > - break; > - case S_IFBLK: > - type = XR_INO_BLKDEV; > - break; > - case S_IFSOCK: > - type = XR_INO_SOCK; > - break; > - case S_IFIFO: > - type = XR_INO_FIFO; > - break; > - default: > - retval++; > - if (!verify_mode) { > - do_warn(_("bad inode type %#o inode %llu\n"), > - (int) (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT), lino); > - if (!no_modify) > - *dirty += clear_dinode(mp, dino, lino); > - else > - *dirty = 1; > - *cleared = 1; > - *used = is_free; > - } else if (!uncertain) { > - do_warn(_("bad inode type %#o inode %llu\n"), > - (int) (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT), lino); > - } > - return 1; > - } > - > - /* > - * type checks for root, realtime inodes, and quota inodes > - */ > - if (lino == mp->m_sb.sb_rootino && type != XR_INO_DIR) { > - do_warn(_("bad inode type for root inode %llu, "), lino); > - type = XR_INO_DIR; > - > - if (!no_modify) { > - do_warn(_("resetting to directory\n")); > - INT_MOD_EXPR(dinoc->di_mode, ARCH_CONVERT, > - &= ~(INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT)); > - INT_MOD_EXPR(dinoc->di_mode, ARCH_CONVERT, > - |= INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFDIR); > - } else { > - do_warn(_("would reset to directory\n")); > - } > - } else if (lino == mp->m_sb.sb_rsumino) { > - do_rt = 1; > - rstring = _("summary"); > - rtype = XR_INO_RTSUM; > - } else if (lino == mp->m_sb.sb_rbmino) { > - do_rt = 1; > - rstring = _("bitmap"); > - rtype = XR_INO_RTBITMAP; > - } else if (lino == mp->m_sb.sb_uquotino) { > - if (type != XR_INO_DATA) { > - do_warn(_("user quota inode has bad type 0x%x\n"), > - INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - mp->m_sb.sb_uquotino = NULLFSINO; > - > - return(1); > - } > - } else if (lino == mp->m_sb.sb_gquotino) { > - if (type != XR_INO_DATA) { > - do_warn(_("group quota inode has bad type 0x%x\n"), > - INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - mp->m_sb.sb_gquotino = NULLFSINO; > - > - return(1); > - } > - } > - > - if (do_rt && type != rtype) { > - type = XR_INO_DATA; > - > - do_warn(_("bad inode type for realtime %s inode %llu, "), > - rstring, lino); > - > - if (!no_modify) { > - do_warn(_("resetting to regular file\n")); > - INT_MOD_EXPR(dinoc->di_mode, ARCH_CONVERT, > - &= ~(INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT)); > - INT_MOD_EXPR(dinoc->di_mode, ARCH_CONVERT, > - |= INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFREG); > - } else { > - do_warn(_("would reset to regular file\n")); > - } > - } > - > - /* > - * only regular files with REALTIME or EXTSIZE flags set can have > - * extsize set, or directories with EXTSZINHERIT. > - */ > - if (INT_GET(dinoc->di_extsize, ARCH_CONVERT) != 0) { > - if ((type == XR_INO_RTDATA) || > - (type == XR_INO_DIR && > - (INT_GET(dinoc->di_flags, ARCH_CONVERT) & > - XFS_DIFLAG_EXTSZINHERIT)) || > - (type == XR_INO_DATA && > - (INT_GET(dinoc->di_flags, ARCH_CONVERT) & > - XFS_DIFLAG_EXTSIZE))) { > - /* s'okay */ ; > - } else { > - do_warn( > - _("bad non-zero extent size %u for non-realtime/extsize inode %llu, "), > - INT_GET(dinoc->di_extsize, ARCH_CONVERT), lino); > - > - if (!no_modify) { > - do_warn(_("resetting to zero\n")); > - dinoc->di_extsize = 0; > - *dirty = 1; > - } else { > - do_warn(_("would reset to zero\n")); > - } > - } > - } > - > - /* > - * for realtime inodes, check sizes to see that > - * they are consistent with the # of realtime blocks. > - * also, verify that they contain only one extent and > - * are extent format files. If anything's wrong, clear > - * the inode -- we'll recreate it in phase 6. > - */ > - if (do_rt && > - ((lino == mp->m_sb.sb_rbmino && > - INT_GET(dinoc->di_size, ARCH_CONVERT) > - != mp->m_sb.sb_rbmblocks * mp->m_sb.sb_blocksize) || > - (lino == mp->m_sb.sb_rsumino && > - INT_GET(dinoc->di_size, ARCH_CONVERT) != mp->m_rsumsize))) { > - > - do_warn(_("bad size %llu for realtime %s inode %llu\n"), > - INT_GET(dinoc->di_size, ARCH_CONVERT), rstring, lino); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > - > - if (do_rt && mp->m_sb.sb_rblocks == 0 && INT_GET(dinoc->di_nextents, ARCH_CONVERT) != 0) { > - do_warn(_("bad # of extents (%u) for realtime %s inode %llu\n"), > - INT_GET(dinoc->di_nextents, ARCH_CONVERT), rstring, lino); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > - > - /* > - * Setup nextents and anextents for blkmap_alloc calls. > - */ > - nextents = INT_GET(dinoc->di_nextents, ARCH_CONVERT); > - if (nextents > INT_GET(dinoc->di_nblocks, ARCH_CONVERT) || nextents > XFS_MAX_INCORE_EXTENTS) > - nextents = 1; > - anextents = INT_GET(dinoc->di_anextents, ARCH_CONVERT); > - if (anextents > INT_GET(dinoc->di_nblocks, ARCH_CONVERT) || anextents > XFS_MAX_INCORE_EXTENTS) > - anextents = 1; > - > - /* > - * general size/consistency checks: > - * > - * if the size <= size of the data fork, directories must be > - * local inodes unlike regular files which would be extent inodes. > - * all the other mentioned types have to have a zero size value. > - * > - * if the size and format don't match, get out now rather than > - * risk trying to process a non-existent extents or btree > - * type data fork. > - */ > - switch (type) { > - case XR_INO_DIR: > - if (INT_GET(dinoc->di_size, ARCH_CONVERT) <= > - XFS_DFORK_DSIZE(dino, mp) && > - (dinoc->di_format != XFS_DINODE_FMT_LOCAL)) { > - do_warn( > -_("mismatch between format (%d) and size (%lld) in directory ino %llu\n"), > - dinoc->di_format, > - INT_GET(dinoc->di_size, ARCH_CONVERT), > - lino); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, > - dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > - if (dinoc->di_format != XFS_DINODE_FMT_LOCAL) > - dblkmap = blkmap_alloc(nextents); > - break; > - case XR_INO_SYMLINK: > - if (process_symlink_extlist(mp, lino, dino)) { > - do_warn(_("bad data fork in symlink %llu\n"), lino); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, > - dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > - if (dinoc->di_format != XFS_DINODE_FMT_LOCAL) > - dblkmap = blkmap_alloc(nextents); > - break; > - case XR_INO_CHRDEV: /* fall through to FIFO case ... */ > - case XR_INO_BLKDEV: /* fall through to FIFO case ... */ > - case XR_INO_SOCK: /* fall through to FIFO case ... */ > - case XR_INO_MOUNTPOINT: /* fall through to FIFO case ... */ > - case XR_INO_FIFO: > - if (process_misc_ino_types(mp, dino, lino, type)) { > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > - break; > - case XR_INO_RTDATA: > - /* > - * if we have no realtime blocks, any inode claiming > - * to be a real-time file is bogus > - */ > - if (mp->m_sb.sb_rblocks == 0) { > - do_warn( > - _("found inode %llu claiming to be a real-time file\n"), > - lino); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > - break; > - case XR_INO_RTBITMAP: > - if (INT_GET(dinoc->di_size, ARCH_CONVERT) != > - (__int64_t)mp->m_sb.sb_rbmblocks * mp->m_sb.sb_blocksize) { > - do_warn( > - _("realtime bitmap inode %llu has bad size %lld (should be %lld)\n"), > - lino, INT_GET(dinoc->di_size, ARCH_CONVERT), > - (__int64_t) mp->m_sb.sb_rbmblocks * > - mp->m_sb.sb_blocksize); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > - dblkmap = blkmap_alloc(nextents); > - break; > - case XR_INO_RTSUM: > - if (INT_GET(dinoc->di_size, ARCH_CONVERT) != mp->m_rsumsize) { > - do_warn( > - _("realtime summary inode %llu has bad size %lld (should be %d)\n"), > - lino, INT_GET(dinoc->di_size, ARCH_CONVERT), > - mp->m_rsumsize); > - > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > - dblkmap = blkmap_alloc(nextents); > - break; > - default: > - break; > - } > - > - /* > - * check for illegal values of forkoff > - */ > - err = 0; > - if (dinoc->di_forkoff != 0) { > - switch (dinoc->di_format) { > - case XFS_DINODE_FMT_DEV: > - if (dinoc->di_forkoff != > - (roundup(sizeof(xfs_dev_t), 8) >> 3)) { > - do_warn( > - _("bad attr fork offset %d in dev inode %llu, should be %d\n"), > - (int) dinoc->di_forkoff, > - lino, > - (int) (roundup(sizeof(xfs_dev_t), 8) >> 3)); > - err = 1; > - } > - break; > - case XFS_DINODE_FMT_UUID: > - if (dinoc->di_forkoff != > - (roundup(sizeof(uuid_t), 8) >> 3)) { > - do_warn( > - _("bad attr fork offset %d in uuid inode %llu, should be %d\n"), > - (int) dinoc->di_forkoff, > - lino, > - (int)(roundup(sizeof(uuid_t), 8) >> 3)); > - err = 1; > - } > - break; > - case XFS_DINODE_FMT_LOCAL: /* fall through ... */ > - case XFS_DINODE_FMT_EXTENTS: /* fall through ... */ > - case XFS_DINODE_FMT_BTREE: { > - if (dinoc->di_forkoff >= (XFS_LITINO(mp) >> 3)) { > - do_warn( > - _("bad attr fork offset %d in inode %llu, max=%d\n"), > - (int) dinoc->di_forkoff, > - lino, XFS_LITINO(mp) >> 3); > - err = 1; > - } > - break; > - } > - default: > - do_error(_("unexpected inode format %d\n"), > - (int) dinoc->di_format); > - break; > - } > - } > - > - if (err) { > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - blkmap_free(dblkmap); > - return(1); > - } > - > - /* > - * check data fork -- if it's bad, clear the inode > - */ > - nextents = 0; > switch (dinoc->di_format) { > case XFS_DINODE_FMT_LOCAL: > - err = process_lclinode(mp, agno, ino, dino, type, > - dirty, &totblocks, &nextents, &dblkmap, > - XFS_DATA_FORK, check_dups); > + err = process_lclinode(mp, agno, ino, dino, type, dirty, > + totblocks, nextents, dblkmap, XFS_DATA_FORK, > + check_dups); > break; > case XFS_DINODE_FMT_EXTENTS: > - err = process_exinode(mp, agno, ino, dino, type, > - dirty, &totblocks, &nextents, &dblkmap, > - XFS_DATA_FORK, check_dups); > + err = process_exinode(mp, agno, ino, dino, type, dirty, > + totblocks, nextents, dblkmap, XFS_DATA_FORK, > + check_dups); > break; > case XFS_DINODE_FMT_BTREE: > - err = process_btinode(mp, agno, ino, dino, type, > - dirty, &totblocks, &nextents, &dblkmap, > - XFS_DATA_FORK, check_dups); > + err = process_btinode(mp, agno, ino, dino, type, dirty, > + totblocks, nextents, dblkmap, XFS_DATA_FORK, > + check_dups); > break; > case XFS_DINODE_FMT_DEV: /* fall through */ > - case XFS_DINODE_FMT_UUID: > err = 0; > break; > default: > do_error(_("unknown format %d, ino %llu (mode = %d)\n"), > - dinoc->di_format, lino, > - INT_GET(dinoc->di_mode, ARCH_CONVERT)); > + dinoc->di_format, lino, be16_to_cpu(dinoc->di_mode)); > } > > if (err) { > - /* > - * problem in the data fork, clear out the inode > - * and get out > - */ > do_warn(_("bad data fork in inode %llu\n"), lino); > - > if (!no_modify) { > *dirty += clear_dinode(mp, dino, lino); > ASSERT(*dirty > 0); > } > - > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - blkmap_free(dblkmap); > - return(1); > + return 1; > } > > if (check_dups) { > @@ -2486,465 +2166,633 @@ _("mismatch between format (%d) and size > switch (dinoc->di_format) { > case XFS_DINODE_FMT_LOCAL: > err = process_lclinode(mp, agno, ino, dino, type, > - dirty, &totblocks, &nextents, &dblkmap, > + dirty, totblocks, nextents, dblkmap, > XFS_DATA_FORK, 0); > break; > case XFS_DINODE_FMT_EXTENTS: > err = process_exinode(mp, agno, ino, dino, type, > - dirty, &totblocks, &nextents, &dblkmap, > + dirty, totblocks, nextents, dblkmap, > XFS_DATA_FORK, 0); > break; > case XFS_DINODE_FMT_BTREE: > err = process_btinode(mp, agno, ino, dino, type, > - dirty, &totblocks, &nextents, &dblkmap, > + dirty, totblocks, nextents, dblkmap, > XFS_DATA_FORK, 0); > break; > case XFS_DINODE_FMT_DEV: /* fall through */ > - case XFS_DINODE_FMT_UUID: > err = 0; > break; > default: > do_error(_("unknown format %d, ino %llu (mode = %d)\n"), > dinoc->di_format, lino, > - INT_GET(dinoc->di_mode, ARCH_CONVERT)); > + be16_to_cpu(dinoc->di_mode)); > } > > - if (no_modify && err != 0) { > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - blkmap_free(dblkmap); > - return(1); > - } > + if (no_modify && err != 0) > + return 1; > > ASSERT(err == 0); > } > + return 0; > +} > > - /* > - * check attribute fork if necessary. attributes are > - * always stored in the regular filesystem. > - */ > +/* > + * Process extended attribute fork in inode > + */ > +static int > +process_inode_attr_fork( > + xfs_mount_t *mp, > + xfs_agnumber_t agno, > + xfs_agino_t ino, > + xfs_dinode_t *dino, > + int type, > + int *dirty, > + xfs_drfsbno_t *atotblocks, > + __uint64_t *anextents, > + int check_dups, > + int extra_attr_check, > + int *retval) > +{ > + xfs_dinode_core_t *dinoc = &dino->di_core; > + xfs_ino_t lino = XFS_AGINO_TO_INO(mp, agno, ino); > + blkmap_t *ablkmap = NULL; > + int repair = 0; > + int err; > + > + if (!XFS_DFORK_Q(dino)) { > + *anextents = 0; > + if (dinoc->di_aformat != XFS_DINODE_FMT_EXTENTS) { > + do_warn(_("bad attribute format %d in inode %llu, "), > + dinoc->di_aformat, lino); > + if (!no_modify) { > + do_warn(_("resetting value\n")); > + dinoc->di_aformat = XFS_DINODE_FMT_EXTENTS; > + *dirty = 1; > + } else > + do_warn(_("would reset value\n")); > + } > + return 0; > + } > > - if (!XFS_DFORK_Q(dino) && > - dinoc->di_aformat != XFS_DINODE_FMT_EXTENTS) { > - do_warn(_("bad attribute format %d in inode %llu, "), > - dinoc->di_aformat, lino); > - if (!no_modify) { > - do_warn(_("resetting value\n")); > - dinoc->di_aformat = XFS_DINODE_FMT_EXTENTS; > - *dirty = 1; > - } else > - do_warn(_("would reset value\n")); > - anextents = 0; > - } else if (XFS_DFORK_Q(dino)) { > + *anextents = be32_to_cpu(dinoc->di_anextents); > + if (*anextents > be64_to_cpu(dinoc->di_nblocks) || > + *anextents > XFS_MAX_INCORE_EXTENTS) > + *anextents = 1; > + > + switch (dinoc->di_aformat) { > + case XFS_DINODE_FMT_LOCAL: > + *anextents = 0; > + err = process_lclinode(mp, agno, ino, dino, type, dirty, > + atotblocks, anextents, &ablkmap, > + XFS_ATTR_FORK, check_dups); > + break; > + case XFS_DINODE_FMT_EXTENTS: > + ablkmap = blkmap_alloc(*anextents); > + *anextents = 0; > + err = process_exinode(mp, agno, ino, dino, type, dirty, > + atotblocks, anextents, &ablkmap, > + XFS_ATTR_FORK, check_dups); > + break; > + case XFS_DINODE_FMT_BTREE: > + ablkmap = blkmap_alloc(*anextents); > + *anextents = 0; > + err = process_btinode(mp, agno, ino, dino, type, dirty, > + atotblocks, anextents, &ablkmap, > + XFS_ATTR_FORK, check_dups); > + break; > + default: > + do_warn(_("illegal attribute format %d, ino %llu\n"), > + dinoc->di_aformat, lino); > + err = 1; > + break; > + } > + > + if (err) { > + /* > + * clear the attribute fork if necessary. we can't > + * clear the inode because we've already put the > + * inode space info into the blockmap. > + * > + * XXX - put the inode onto the "move it" list and > + * log the the attribute scrubbing > + */ > + do_warn(_("bad attribute fork in inode %llu"), lino); > + > + if (!no_modify) { > + if (delete_attr_ok) { > + do_warn(_(", clearing attr fork\n")); > + *dirty += clear_dinode_attr(mp, dino, lino); > + dinoc->di_aformat = XFS_DINODE_FMT_LOCAL; > + } else { > + do_warn("\n"); > + *dirty += clear_dinode(mp, dino, lino); > + } > + ASSERT(*dirty > 0); > + } else { > + do_warn(_(", would clear attr fork\n")); > + } > + > + *atotblocks = 0; > + *anextents = 0; > + blkmap_free(ablkmap); > + *retval = 1; > + > + return delete_attr_ok ? 0 : 1; > + } > + > + if (check_dups) { > switch (dinoc->di_aformat) { > case XFS_DINODE_FMT_LOCAL: > - anextents = 0; > err = process_lclinode(mp, agno, ino, dino, > - type, dirty, &atotblocks, &anextents, &ablkmap, > - XFS_ATTR_FORK, check_dups); > + type, dirty, atotblocks, anextents, > + &ablkmap, XFS_ATTR_FORK, 0); > break; > case XFS_DINODE_FMT_EXTENTS: > - ablkmap = blkmap_alloc(anextents); > - anextents = 0; > err = process_exinode(mp, agno, ino, dino, > - type, dirty, &atotblocks, &anextents, &ablkmap, > - XFS_ATTR_FORK, check_dups); > + type, dirty, atotblocks, anextents, > + &ablkmap, XFS_ATTR_FORK, 0); > break; > case XFS_DINODE_FMT_BTREE: > - ablkmap = blkmap_alloc(anextents); > - anextents = 0; > err = process_btinode(mp, agno, ino, dino, > - type, dirty, &atotblocks, &anextents, &ablkmap, > - XFS_ATTR_FORK, check_dups); > + type, dirty, atotblocks, anextents, > + &ablkmap, XFS_ATTR_FORK, 0); > break; > default: > - anextents = 0; > - do_warn(_("illegal attribute format %d, ino %llu\n"), > - dinoc->di_aformat, lino); > - err = 1; > - break; > + do_error(_("illegal attribute fmt %d, ino %llu\n"), > + dinoc->di_aformat, lino); > } > > - if (err) { > - /* > - * clear the attribute fork if necessary. we can't > - * clear the inode because we've already put the > - * inode space info into the blockmap. > - * > - * XXX - put the inode onto the "move it" list and > - * log the the attribute scrubbing > - */ > - do_warn(_("bad attribute fork in inode %llu"), lino); > + if (no_modify && err != 0) { > + blkmap_free(ablkmap); > + return 1; > + } > + > + ASSERT(err == 0); > + } > + > + /* > + * do attribute semantic-based consistency checks now > + */ > > + /* get this only in phase 3, not in both phase 3 and 4 */ > + if (extra_attr_check && > + process_attributes(mp, lino, dino, ablkmap, &repair)) { > + do_warn(_("problem with attribute contents in inode %llu\n"), > + lino); > + if (!repair) { > + /* clear attributes if not done already */ > if (!no_modify) { > - if (delete_attr_ok) { > - do_warn(_(", clearing attr fork\n")); > - *dirty += clear_dinode_attr(mp, > - dino, lino); > - } else { > - do_warn("\n"); > - *dirty += clear_dinode(mp, > - dino, lino); > - } > - ASSERT(*dirty > 0); > + *dirty += clear_dinode_attr(mp, dino, lino); > + dinoc->di_aformat = XFS_DINODE_FMT_LOCAL; > } else { > - do_warn(_(", would clear attr fork\n")); > + do_warn(_("would clear attr fork\n")); > } > + *atotblocks = 0; > + *anextents = 0; > + } > + else { > + *dirty = 1; /* it's been repaired */ > + } > + } > + blkmap_free(ablkmap); > + return 0; > +} > > - atotblocks = 0; > - anextents = 0; > +/* > + * check nlinks feature, if it's a version 1 inode, > + * just leave nlinks alone. even if it's set wrong, > + * it'll be reset when read in. > + */ > > - if (delete_attr_ok) { > - if (!no_modify) > - dinoc->di_aformat = XFS_DINODE_FMT_LOCAL; > +static int > +process_check_inode_nlink_version( > + xfs_dinode_core_t *dinoc, > + xfs_ino_t lino) > +{ > + int dirty = 0; > + > + if (dinoc->di_version > XFS_DINODE_VERSION_1 && !fs_inode_nlink) { > + /* > + * do we have a fs/inode version mismatch with a valid > + * version 2 inode here that has to stay version 2 or > + * lose links? > + */ > + if (be32_to_cpu(dinoc->di_nlink) > XFS_MAXLINK_1) { > + /* > + * yes. are nlink inodes allowed? > + */ > + if (fs_inode_nlink_allowed) { > + /* > + * yes, update status variable which will > + * cause sb to be updated later. > + */ > + fs_inode_nlink = 1; > + do_warn(_("version 2 inode %llu claims > %u links, "), > + lino, XFS_MAXLINK_1); > + if (!no_modify) { > + do_warn(_("updating superblock " > + "version number\n")); > + } else { > + do_warn(_("would update superblock " > + "version number\n")); > + } > } else { > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - blkmap_free(dblkmap); > - blkmap_free(ablkmap); > + /* > + * no, have to convert back to onlinks > + * even if we lose some links > + */ > + do_warn(_("WARNING: version 2 inode %llu " > + "claims > %u links, "), > + lino, XFS_MAXLINK_1); > + if (!no_modify) { > + do_warn(_("converting back to version 1,\n" > + "this may destroy %d links\n"), > + be32_to_cpu(dinoc->di_nlink) - > + XFS_MAXLINK_1); > + > + dinoc->di_version = XFS_DINODE_VERSION_1; > + dinoc->di_nlink = cpu_to_be32(XFS_MAXLINK_1); > + dinoc->di_onlink = cpu_to_be16(XFS_MAXLINK_1); > + dirty = 1; > + } else { > + do_warn(_("would convert back to version 1,\n" > + "\tthis might destroy %d links\n"), > + be32_to_cpu(dinoc->di_nlink) - > + XFS_MAXLINK_1); > + } > } > - return(1); > + } else { > + /* > + * do we have a v2 inode that we could convert back > + * to v1 without losing any links? if we do and > + * we have a mismatch between superblock bits and the > + * version bit, alter the version bit in this case. > + * > + * the case where we lost links was handled above. > + */ > + do_warn(_("found version 2 inode %llu, "), lino); > + if (!no_modify) { > + do_warn(_("converting back to version 1\n")); > + dinoc->di_version = XFS_DINODE_VERSION_1; > + dinoc->di_onlink = cpu_to_be16( > + be32_to_cpu(dinoc->di_nlink)); > + dirty = 1; > + } else { > + do_warn(_("would convert back to version 1\n")); > + } > + } > + } > > - } else if (check_dups) { > - switch (dinoc->di_aformat) { > - case XFS_DINODE_FMT_LOCAL: > - err = process_lclinode(mp, agno, ino, dino, > - type, dirty, &atotblocks, &anextents, > - &ablkmap, XFS_ATTR_FORK, 0); > - break; > - case XFS_DINODE_FMT_EXTENTS: > - err = process_exinode(mp, agno, ino, dino, > - type, dirty, &atotblocks, &anextents, > - &ablkmap, XFS_ATTR_FORK, 0); > - break; > - case XFS_DINODE_FMT_BTREE: > - err = process_btinode(mp, agno, ino, dino, > - type, dirty, &atotblocks, &anextents, > - &ablkmap, XFS_ATTR_FORK, 0); > - break; > - default: > - do_error( > - _("illegal attribute fmt %d, ino %llu\n"), > - dinoc->di_aformat, lino); > + /* > + * ok, if it's still a version 2 inode, it's going > + * to stay a version 2 inode. it should have a zero > + * onlink field, so clear it. > + */ > + if (dinoc->di_version > XFS_DINODE_VERSION_1 && > + dinoc->di_onlink != 0 && fs_inode_nlink > 0) { > + if (!no_modify) { > + do_warn(_("clearing obsolete nlink field in " > + "version 2 inode %llu, was %d, now 0\n"), > + lino, be16_to_cpu(dinoc->di_onlink)); > + dinoc->di_onlink = 0; > + dirty = 1; > + } else { > + do_warn(_("would clear obsolete nlink field in " > + "version 2 inode %llu, currently %d\n"), > + lino, be16_to_cpu(dinoc->di_onlink)); > + } > + } > + return dirty; > +} > + > +/* > + * returns 0 if the inode is ok, 1 if the inode is corrupt > + * check_dups can be set to 1 *only* when called by the > + * first pass of the duplicate block checking of phase 4. > + * *dirty is set > 0 if the dinode has been altered and > + * needs to be written out. > + * > + * for detailed, info, look at process_dinode() comments. > + */ > +/* ARGSUSED */ > +int > +process_dinode_int(xfs_mount_t *mp, > + xfs_dinode_t *dino, > + xfs_agnumber_t agno, > + xfs_agino_t ino, > + int was_free, /* 1 if inode is currently free */ > + int *dirty, /* out == > 0 if inode is now dirty */ > + int *used, /* out == 1 if inode is in use */ > + int verify_mode, /* 1 == verify but don't modify inode */ > + int uncertain, /* 1 == inode is uncertain */ > + int ino_discovery, /* 1 == check dirs for unknown inodes */ > + int check_dups, /* 1 == check if inode claims > + * duplicate blocks */ > + int extra_attr_check, /* 1 == do attribute format and value checks */ > + int *isa_dir, /* out == 1 if inode is a directory */ > + xfs_ino_t *parent) /* out -- parent if ino is a dir */ > +{ > + xfs_drfsbno_t totblocks = 0; > + xfs_drfsbno_t atotblocks = 0; > + xfs_dinode_core_t *dinoc; > + int di_mode; > + int type; > + int retval = 0; > + __uint64_t nextents; > + __uint64_t anextents; > + xfs_ino_t lino; > + const int is_free = 0; > + const int is_used = 1; > + blkmap_t *dblkmap = NULL; > + > + *dirty = *isa_dir = 0; > + *used = is_used; > + type = XR_INO_UNKNOWN; > + > + dinoc = &dino->di_core; > + lino = XFS_AGINO_TO_INO(mp, agno, ino); > + di_mode = be16_to_cpu(dinoc->di_mode); > + > + /* > + * if in verify mode, don't modify the inode. > + * > + * if correcting, reset stuff that has known values > + * > + * if in uncertain mode, be silent on errors since we're > + * trying to find out if these are inodes as opposed > + * to assuming that they are. Just return the appropriate > + * return code in that case. > + * > + * If uncertain is set, verify_mode MUST be set. > + */ > + ASSERT(uncertain == 0 || verify_mode != 0); > + > + if (be16_to_cpu(dinoc->di_magic) != XFS_DINODE_MAGIC) { > + retval = 1; > + if (!uncertain) > + do_warn(_("bad magic number 0x%x on inode %llu\n"), > + be16_to_cpu(dinoc->di_magic), lino); > + if (!verify_mode) { > + if (!no_modify) { > + do_warn(_("resetting magic number\n")); > + dinoc->di_magic = cpu_to_be16(XFS_DINODE_MAGIC); > + *dirty = 1; > + } else > + do_warn(_("would reset magic number\n")); > + } > + } > + > + if (!XFS_DINODE_GOOD_VERSION(dinoc->di_version) || > + (!fs_inode_nlink && dinoc->di_version > XFS_DINODE_VERSION_1)) { > + retval = 1; > + if (!uncertain) > + do_warn(_("bad version number 0x%x on inode %llu, "), > + dinoc->di_version, lino); > + if (!verify_mode) { > + if (!no_modify) { > + do_warn(_("resetting version number\n")); > + dinoc->di_version = (fs_inode_nlink) ? > + XFS_DINODE_VERSION_2 : > + XFS_DINODE_VERSION_1; > + *dirty = 1; > + } else > + do_warn(_("would reset version number\n")); > + } > + } > + > + /* > + * blow out of here if the inode size is < 0 > + */ > + if ((xfs_fsize_t)be64_to_cpu(dinoc->di_size) < 0) { > + if (!uncertain) > + do_warn(_("bad (negative) size %lld on inode %llu\n"), > + be64_to_cpu(dinoc->di_size), lino); > + if (verify_mode) > + return 1; > + goto clear_bad_out; > + } > + > + /* > + * if not in verify mode, check to sii if the inode and imap > + * agree that the inode is free > + */ > + if (!verify_mode && di_mode == 0) { > + /* > + * was_free value is not meaningful if we're in verify mode > + */ > + if (was_free) { > + /* > + * easy case, inode free -- inode and map agree, clear > + * it just in case to ensure that format, etc. are > + * set correctly > + */ > + if (!no_modify) > + *dirty += clear_dinode(mp, dino, lino); > + *used = is_free; > + return 0; > + } > + /* > + * the inode looks free but the map says it's in use. > + * clear the inode just to be safe and mark the inode > + * free. > + */ > + do_warn(_("imap claims a free inode %llu is in use, "), lino); > + if (!no_modify) { > + do_warn(_("correcting imap and clearing inode\n")); > + if (clear_dinode(mp, dino, lino)) { > + retval = 1; > + *dirty = 1; > } > + } else > + do_warn(_("would correct imap and clear inode\n")); > + *used = is_free; > + return retval; > + } > > - if (no_modify && err != 0) { > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - blkmap_free(dblkmap); > - blkmap_free(ablkmap); > - return(1); > - } > + /* > + * because of the lack of any write ordering guarantee, it's > + * possible that the core got updated but the forks didn't. > + * so rather than be ambitious (and probably incorrect), > + * if there's an inconsistency, we get conservative and > + * just pitch the file. blow off checking formats of > + * free inodes since technically any format is legal > + * as we reset the inode when we re-use it. > + */ > + if (di_mode != 0 && check_dinode_mode_format(dinoc) != 0) { > + if (!uncertain) > + do_warn(_("bad inode format in inode %llu\n"), lino); > + if (verify_mode) > + return 1; > + goto clear_bad_out; > + } > > - ASSERT(err == 0); > - } > + if (verify_mode) > + return retval; > > - /* > - * do attribute semantic-based consistency checks now > - */ > + /* > + * clear the next unlinked field if necessary on a good > + * inode only during phase 4 -- when checking for inodes > + * referencing duplicate blocks. then it's safe because > + * we've done the inode discovery and have found all the inodes > + * we're going to find. check_dups is set to 1 only during > + * phase 4. Ugly. > + */ > + if (check_dups && !no_modify) > + *dirty += clear_dinode_unlinked(mp, dino); > > - /* get this only in phase 3, not in both phase 3 and 4 */ > - if (extra_attr_check) { > - if ((err = process_attributes(mp, lino, dino, ablkmap, > - &repair))) { > - do_warn( > - _("problem with attribute contents in inode %llu\n"), lino); > - if(!repair) { > - /* clear attributes if not done already */ > - if (!no_modify) { > - *dirty += clear_dinode_attr( > - mp, dino, lino); > - dinoc->di_aformat = > - XFS_DINODE_FMT_LOCAL; > - } else { > - do_warn( > - _("would clear attr fork\n")); > - } > - atotblocks = 0; > - anextents = 0; > - } > - else { > - *dirty = 1; /* it's been repaired */ > - } > - } > - } > - blkmap_free(ablkmap); > + /* set type and map type info */ > > - } else > - anextents = 0; > + switch (di_mode & S_IFMT) { > + case S_IFDIR: > + type = XR_INO_DIR; > + *isa_dir = 1; > + break; > + case S_IFREG: > + if (be16_to_cpu(dinoc->di_flags) & XFS_DIFLAG_REALTIME) > + type = XR_INO_RTDATA; > + else if (lino == mp->m_sb.sb_rbmino) > + type = XR_INO_RTBITMAP; > + else if (lino == mp->m_sb.sb_rsumino) > + type = XR_INO_RTSUM; > + else > + type = XR_INO_DATA; > + break; > + case S_IFLNK: > + type = XR_INO_SYMLINK; > + break; > + case S_IFCHR: > + type = XR_INO_CHRDEV; > + break; > + case S_IFBLK: > + type = XR_INO_BLKDEV; > + break; > + case S_IFSOCK: > + type = XR_INO_SOCK; > + break; > + case S_IFIFO: > + type = XR_INO_FIFO; > + break; > + default: > + do_warn(_("bad inode type %#o inode %llu\n"), > + di_mode & S_IFMT, lino); > + goto clear_bad_out; > + } > > /* > - * enforce totblocks is 0 for misc types > - */ > - if (process_misc_ino_types_blocks(totblocks, lino, type)) { > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - blkmap_free(dblkmap); > - return(1); > - } > + * type checks for superblock inodes > + */ > + if (process_check_sb_inodes(mp, dinoc, lino, &type, dirty) != 0) > + goto clear_bad_out; > > /* > - * correct space counters if required > + * only regular files with REALTIME or EXTSIZE flags set can have > + * extsize set, or directories with EXTSZINHERIT. > */ > - if (totblocks + atotblocks != INT_GET(dinoc->di_nblocks, ARCH_CONVERT)) { > - if (!no_modify) { > - do_warn( > - _("correcting nblocks for inode %llu, was %llu - counted %llu\n"), > - lino, INT_GET(dinoc->di_nblocks, ARCH_CONVERT), > - totblocks + atotblocks); > - *dirty = 1; > - INT_SET(dinoc->di_nblocks, ARCH_CONVERT, totblocks + atotblocks); > - } else { > - do_warn( > - _("bad nblocks %llu for inode %llu, would reset to %llu\n"), > - INT_GET(dinoc->di_nblocks, ARCH_CONVERT), lino, > - totblocks + atotblocks); > + if (dinoc->di_extsize != 0) { > + if ((type == XR_INO_RTDATA) || > + (type == XR_INO_DIR && (be16_to_cpu(dinoc->di_flags) & > + XFS_DIFLAG_EXTSZINHERIT)) || > + (type == XR_INO_DATA && (be16_to_cpu(dinoc->di_flags) & > + XFS_DIFLAG_EXTSIZE))) { > + /* s'okay */ ; > + } else { > + do_warn(_("bad non-zero extent size %u for " > + "non-realtime/extsize inode %llu, "), > + be32_to_cpu(dinoc->di_extsize), lino); > + if (!no_modify) { > + do_warn(_("resetting to zero\n")); > + dinoc->di_extsize = 0; > + *dirty = 1; > + } else > + do_warn(_("would reset to zero\n")); > } > } > > - if (nextents > MAXEXTNUM) { > - do_warn(_("too many data fork extents (%llu) in inode %llu\n"), > - nextents, lino); > + /* > + * general size/consistency checks: > + */ > + if (process_check_inode_sizes(mp, dino, lino, type) != 0) > + goto clear_bad_out; > > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - blkmap_free(dblkmap); > + /* > + * check for illegal values of forkoff > + */ > + if (process_check_inode_forkoff(mp, dinoc, lino) != 0) > + goto clear_bad_out; > > - return(1); > - } > - if (nextents != INT_GET(dinoc->di_nextents, ARCH_CONVERT)) { > - if (!no_modify) { > - do_warn( > - _("correcting nextents for inode %llu, was %d - counted %llu\n"), > - lino, INT_GET(dinoc->di_nextents, ARCH_CONVERT), > - nextents); > - *dirty = 1; > - INT_SET(dinoc->di_nextents, ARCH_CONVERT, > - (xfs_extnum_t) nextents); > - } else { > - do_warn( > - _("bad nextents %d for inode %llu, would reset to %llu\n"), > - INT_GET(dinoc->di_nextents, ARCH_CONVERT), > - lino, nextents); > - } > - } > + /* > + * check data fork -- if it's bad, clear the inode > + */ > + if (process_inode_data_fork(mp, agno, ino, dino, type, dirty, > + &totblocks, &nextents, &dblkmap, check_dups) != 0) > + goto bad_out; > > - if (anextents > MAXAEXTNUM) { > - do_warn(_("too many attr fork extents (%llu) in inode %llu\n"), > - anextents, lino); > + /* > + * check attribute fork if necessary. attributes are > + * always stored in the regular filesystem. > + */ > + if (process_inode_attr_fork(mp, agno, ino, dino, type, dirty, > + &atotblocks, &anextents, check_dups, extra_attr_check, > + &retval)) > + goto bad_out; > > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - blkmap_free(dblkmap); > - return(1); > - } > - if (anextents != INT_GET(dinoc->di_anextents, ARCH_CONVERT)) { > - if (!no_modify) { > - do_warn( > - _("correcting anextents for inode %llu, was %d - counted %llu\n"), > - lino, > - INT_GET(dinoc->di_anextents, ARCH_CONVERT), > - anextents); > - *dirty = 1; > - INT_SET(dinoc->di_anextents, ARCH_CONVERT, > - (xfs_aextnum_t) anextents); > - } else { > - do_warn( > - _("bad anextents %d for inode %llu, would reset to %llu\n"), > - INT_GET(dinoc->di_anextents, ARCH_CONVERT), > - lino, anextents); > - } > - } > + /* > + * enforce totblocks is 0 for misc types > + */ > + if (process_misc_ino_types_blocks(totblocks, lino, type)) > + goto clear_bad_out; > + > + /* > + * correct space counters if required > + */ > + if (process_inode_blocks_and_extents(dinoc, totblocks + atotblocks, > + nextents, anextents, lino, dirty) != 0) > + goto clear_bad_out; > > /* > * do any semantic type-based checking here > */ > switch (type) { > case XR_INO_DIR: > - if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > - err = process_dir2(mp, lino, dino, ino_discovery, > - dirty, "", parent, dblkmap); > - else > - err = process_dir(mp, lino, dino, ino_discovery, > - dirty, "", parent, dblkmap); > - if (err) > - do_warn( > - _("problem with directory contents in inode %llu\n"), > - lino); > - break; > - case XR_INO_RTBITMAP: > - /* process_rtbitmap XXX */ > - err = 0; > - break; > - case XR_INO_RTSUM: > - /* process_rtsummary XXX */ > - err = 0; > + if (process_dir2(mp, lino, dino, ino_discovery, dirty, "", > + parent, dblkmap) != 0) { > + do_warn(_("problem with directory contents in " > + "inode %llu\n"), lino); > + goto clear_bad_out; > + } > break; > case XR_INO_SYMLINK: > - if ((err = process_symlink(mp, lino, dino, dblkmap))) > + if (process_symlink(mp, lino, dino, dblkmap) != 0) { > do_warn(_("problem with symbolic link in inode %llu\n"), > lino); > - break; > - case XR_INO_DATA: /* fall through to FIFO case ... */ > - case XR_INO_RTDATA: /* fall through to FIFO case ... */ > - case XR_INO_CHRDEV: /* fall through to FIFO case ... */ > - case XR_INO_BLKDEV: /* fall through to FIFO case ... */ > - case XR_INO_SOCK: /* fall through to FIFO case ... */ > - case XR_INO_FIFO: > - err = 0; > + goto clear_bad_out; > + } > break; > default: > - printf(_("Unexpected inode type\n")); > - abort(); > + break; > } > > - if (dblkmap) > - blkmap_free(dblkmap); > - > - if (err) { > - /* > - * problem in the inode type-specific semantic > - * checking, clear out the inode and get out > - */ > - if (!no_modify) { > - *dirty += clear_dinode(mp, dino, lino); > - ASSERT(*dirty > 0); > - } > - *cleared = 1; > - *used = is_free; > - *isa_dir = 0; > - > - return(1); > - } > + blkmap_free(dblkmap); > > /* > * check nlinks feature, if it's a version 1 inode, > * just leave nlinks alone. even if it's set wrong, > * it'll be reset when read in. > */ > - if (dinoc->di_version > XFS_DINODE_VERSION_1 && !fs_inode_nlink) { > - /* > - * do we have a fs/inode version mismatch with a valid > - * version 2 inode here that has to stay version 2 or > - * lose links? > - */ > - if (INT_GET(dinoc->di_nlink, ARCH_CONVERT) > XFS_MAXLINK_1) { > - /* > - * yes. are nlink inodes allowed? > - */ > - if (fs_inode_nlink_allowed) { > - /* > - * yes, update status variable which will > - * cause sb to be updated later. > - */ > - fs_inode_nlink = 1; > - do_warn( > - _("version 2 inode %llu claims > %u links, "), > - lino, XFS_MAXLINK_1); > - if (!no_modify) { > - do_warn( > - _("updating superblock version number\n")); > - } else { > - do_warn( > - _("would update superblock version number\n")); > - } > - } else { > - /* > - * no, have to convert back to onlinks > - * even if we lose some links > - */ > - do_warn( > - _("WARNING: version 2 inode %llu claims > %u links, "), > - lino, XFS_MAXLINK_1); > - if (!no_modify) { > - do_warn( > - _("converting back to version 1,\n\tthis may destroy %d links\n"), > - INT_GET(dinoc->di_nlink, > - ARCH_CONVERT) > - - XFS_MAXLINK_1); > - > - dinoc->di_version = > - XFS_DINODE_VERSION_1; > - INT_SET(dinoc->di_nlink, ARCH_CONVERT, > - XFS_MAXLINK_1); > - INT_SET(dinoc->di_onlink, ARCH_CONVERT, > - XFS_MAXLINK_1); > - > - *dirty = 1; > - } else { > - do_warn( > - _("would convert back to version 1,\n\tthis might destroy %d links\n"), > - INT_GET(dinoc->di_nlink, > - ARCH_CONVERT) > - - XFS_MAXLINK_1); > - } > - } > - } else { > - /* > - * do we have a v2 inode that we could convert back > - * to v1 without losing any links? if we do and > - * we have a mismatch between superblock bits and the > - * version bit, alter the version bit in this case. > - * > - * the case where we lost links was handled above. > - */ > - do_warn(_("found version 2 inode %llu, "), lino); > - if (!no_modify) { > - do_warn(_("converting back to version 1\n")); > - > - dinoc->di_version = > - XFS_DINODE_VERSION_1; > - INT_SET(dinoc->di_onlink, ARCH_CONVERT, > - INT_GET(dinoc->di_nlink, ARCH_CONVERT)); > - > - *dirty = 1; > - } else { > - do_warn(_("would convert back to version 1\n")); > - } > - } > - } > + *dirty = process_check_inode_nlink_version(dinoc, lino); > > - /* > - * ok, if it's still a version 2 inode, it's going > - * to stay a version 2 inode. it should have a zero > - * onlink field, so clear it. > - */ > - if (dinoc->di_version > XFS_DINODE_VERSION_1 && > - INT_GET(dinoc->di_onlink, ARCH_CONVERT) > 0 && > - fs_inode_nlink > 0) { > - if (!no_modify) { > - do_warn( > -_("clearing obsolete nlink field in version 2 inode %llu, was %d, now 0\n"), > - lino, INT_GET(dinoc->di_onlink, ARCH_CONVERT)); > - dinoc->di_onlink = 0; > - *dirty = 1; > - } else { > - do_warn( > -_("would clear obsolete nlink field in version 2 inode %llu, currently %d\n"), > - lino, INT_GET(dinoc->di_onlink, ARCH_CONVERT)); > - *dirty = 1; > - } > - } > + return retval; > > - return(retval > 0 ? 1 : 0); > +clear_bad_out: > + if (!no_modify) { > + *dirty += clear_dinode(mp, dino, lino); > + ASSERT(*dirty > 0); > + } > +bad_out: > + *used = is_free; > + *isa_dir = 0; > + blkmap_free(dblkmap); > + return 1; > } > > /* > @@ -2983,8 +2831,6 @@ _("would clear obsolete nlink field in v > * claimed blocks using the bitmap. > * Outs: > * dirty -- whether we changed the inode (1 == yes) > - * cleared -- whether we cleared the inode (1 == yes). In > - * no modify mode, if we would have cleared it > * used -- 1 if the inode is used, 0 if free. In no modify > * mode, whether the inode should be used or free > * isa_dir -- 1 if the inode is a directory, 0 if not. In > @@ -2994,30 +2840,29 @@ _("would clear obsolete nlink field in v > */ > > int > -process_dinode(xfs_mount_t *mp, > - xfs_dinode_t *dino, > - xfs_agnumber_t agno, > - xfs_agino_t ino, > - int was_free, > - int *dirty, > - int *cleared, > - int *used, > - int ino_discovery, > - int check_dups, > - int extra_attr_check, > - int *isa_dir, > - xfs_ino_t *parent) > +process_dinode( > + xfs_mount_t *mp, > + xfs_dinode_t *dino, > + xfs_agnumber_t agno, > + xfs_agino_t ino, > + int was_free, > + int *dirty, > + int *used, > + int ino_discovery, > + int check_dups, > + int extra_attr_check, > + int *isa_dir, > + xfs_ino_t *parent) > { > - const int verify_mode = 0; > - const int uncertain = 0; > + const int verify_mode = 0; > + const int uncertain = 0; > > #ifdef XR_INODE_TRACE > fprintf(stderr, "processing inode %d/%d\n", agno, ino); > #endif > - return(process_dinode_int(mp, dino, agno, ino, was_free, dirty, > - cleared, used, verify_mode, uncertain, > - ino_discovery, check_dups, extra_attr_check, > - isa_dir, parent)); > + return process_dinode_int(mp, dino, agno, ino, was_free, dirty, used, > + verify_mode, uncertain, ino_discovery, > + check_dups, extra_attr_check, isa_dir, parent); > } > > /* > @@ -3027,25 +2872,24 @@ process_dinode(xfs_mount_t *mp, > * if the inode passes the cursory sanity check, 1 otherwise. > */ > int > -verify_dinode(xfs_mount_t *mp, > - xfs_dinode_t *dino, > - xfs_agnumber_t agno, > - xfs_agino_t ino) > -{ > - xfs_ino_t parent; > - int cleared = 0; > - int used = 0; > - int dirty = 0; > - int isa_dir = 0; > - const int verify_mode = 1; > - const int check_dups = 0; > - const int ino_discovery = 0; > - const int uncertain = 0; > - > - return(process_dinode_int(mp, dino, agno, ino, 0, &dirty, > - &cleared, &used, verify_mode, > - uncertain, ino_discovery, check_dups, > - 0, &isa_dir, &parent)); > +verify_dinode( > + xfs_mount_t *mp, > + xfs_dinode_t *dino, > + xfs_agnumber_t agno, > + xfs_agino_t ino) > +{ > + xfs_ino_t parent; > + int used = 0; > + int dirty = 0; > + int isa_dir = 0; > + const int verify_mode = 1; > + const int check_dups = 0; > + const int ino_discovery = 0; > + const int uncertain = 0; > + > + return process_dinode_int(mp, dino, agno, ino, 0, &dirty, &used, > + verify_mode, uncertain, ino_discovery, > + check_dups, 0, &isa_dir, &parent); > } > > /* > @@ -3054,23 +2898,22 @@ verify_dinode(xfs_mount_t *mp, > * returns 0 if the inode passes the cursory sanity check, 1 otherwise. > */ > int > -verify_uncertain_dinode(xfs_mount_t *mp, > - xfs_dinode_t *dino, > - xfs_agnumber_t agno, > - xfs_agino_t ino) > -{ > - xfs_ino_t parent; > - int cleared = 0; > - int used = 0; > - int dirty = 0; > - int isa_dir = 0; > - const int verify_mode = 1; > - const int check_dups = 0; > - const int ino_discovery = 0; > - const int uncertain = 1; > - > - return(process_dinode_int(mp, dino, agno, ino, 0, &dirty, > - &cleared, &used, verify_mode, > - uncertain, ino_discovery, check_dups, > - 0, &isa_dir, &parent)); > +verify_uncertain_dinode( > + xfs_mount_t *mp, > + xfs_dinode_t *dino, > + xfs_agnumber_t agno, > + xfs_agino_t ino) > +{ > + xfs_ino_t parent; > + int used = 0; > + int dirty = 0; > + int isa_dir = 0; > + const int verify_mode = 1; > + const int check_dups = 0; > + const int ino_discovery = 0; > + const int uncertain = 1; > + > + return process_dinode_int(mp, dino, agno, ino, 0, &dirty, &used, > + verify_mode, uncertain, ino_discovery, > + check_dups, 0, &isa_dir, &parent); > } > > =========================================================================== > xfsprogs/repair/dinode.h > =========================================================================== > > --- a/xfsprogs/repair/dinode.h 2007-11-15 17:24:33.000000000 +1100 > +++ b/xfsprogs/repair/dinode.h 2007-11-15 17:22:18.290409320 +1100 > @@ -84,7 +84,6 @@ process_dinode(xfs_mount_t *mp, > xfs_agino_t ino, > int was_free, > int *dirty, > - int *tossit, > int *used, > int check_dirs, > int check_dups, From owner-xfs@oss.sgi.com Tue Jan 15 18:26:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 18:26:53 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99,MISSING_MIMEOLE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G2Qld1029113 for ; Tue, 15 Jan 2008 18:26:48 -0800 X-ASG-Debug-ID: 1200450418-17e6021d0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from arsat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 88B91C52615 for ; Tue, 15 Jan 2008 18:26:59 -0800 (PST) Received: from arsat.com (103.185-225-89.dsl.completel.net [89.225.185.103]) by cuda.sgi.com with SMTP id zxeHKCRWmnib7LRc for ; Tue, 15 Jan 2008 18:26:59 -0800 (PST) Received: from cuda-allmx.sgi.com by 89.225.185.103 (Postfix) with ESMTP id 31fnLeTJ77Sp for ; Wed, 16 Jan 2008 04:23:40 +0100 Received: from (root@localhost) by cuda-allmx.sgi.com (8.9.3/8.9.3) id f1ofZ3woF36u for ; Wed, 16 Jan 2008 04:23:40 +0100 From: "Della Hope" Reply-To: "Della Hope" Message-ID: <0927609844.1418275255@arsat.com> Date: Wed, 16 Jan 2008 04:23:40 +0100 To: X-ASG-Orig-Subj: Amateur dildoing her big pussy Subject: ***** SUSPECTED SPAM ***** Amateur dildoing her big pussy MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 080115-0, 15/01/2008), Outbound message X-Antivirus-Status: Clean X-Barracuda-Connect: 103.185-225-89.dsl.completel.net[89.225.185.103] X-Barracuda-Start-Time: 1200450425 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3423 1.0000 -0.1804 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 2.61 X-Barracuda-Spam-Status: Yes, SCORE=2.61 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=SARE_ADLTSUB2, SARE_ADULT2, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39639 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.80 SARE_ADLTSUB2 Contains possible adult words 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.99 SARE_ADULT2 BODY: Contains adult material X-Priority: 5 (Lowest) X-MSMail-Priority: Low Importance: Low X-Barracuda-Spam-Flag: YES X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14139 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dianeqacm@arsat.com Precedence: bulk X-list: xfs GreatAttract dot com hemophiliac oarhole ankylotomy sambas inviscate antihistamine vancourier spret disestablishes precyclonic prorecognition stillmen sclerobase diazin pink peacockishness cajoles bowed From owner-xfs@oss.sgi.com Tue Jan 15 18:33:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 18:33:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0G2Wvpa029749 for ; Tue, 15 Jan 2008 18:33:00 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22564; Wed, 16 Jan 2008 13:33:10 +1100 Date: Wed, 16 Jan 2008 13:33:50 +1100 To: "Chandan Talukdar" Subject: Re: [REVIEW] Refactor xfs_repair's process_dinode_int From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <4782B72D.8070208@agami.com> <47833C0F.6070206@agami.com> <478D1899.9080201@agami.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14140 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 16 Jan 2008 11:51:21 +1100, Barry Naujok wrote: > On Wed, 16 Jan 2008 07:33:29 +1100, Chandan Talukdar > wrote: > >> Hi Barry, >> >> - In process_dinode_int(), we should be checking for 'dblkmap' not >> being NULL before freeing it. There are a few error conditions which >> can cause the control to go to 'clear_bad_out' with dblkmap being NULL. > > freeing a NULL is valid My bad! Yes, blkmap_free() doesn't check for a NULL pointer before going through the structure. I'll fix this up. Regards, Barry. From owner-xfs@oss.sgi.com Tue Jan 15 19:10:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 19:10:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0G3AkX2031981 for ; Tue, 15 Jan 2008 19:10:50 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA23648; Wed, 16 Jan 2008 14:10:55 +1100 Message-ID: <478D75C2.5010004@sgi.com> Date: Wed, 16 Jan 2008 14:10:58 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Barry Naujok CC: Chandan Talukdar , "xfs@oss.sgi.com" Subject: Re: [REVIEW] Refactor xfs_repair's process_dinode_int References: <4782B72D.8070208@agami.com> <47833C0F.6070206@agami.com> <478D1899.9080201@agami.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14141 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Not that it is a big deal....but my 2 cents... Barry Naujok wrote: > On Wed, 16 Jan 2008 07:33:29 +1100, Chandan Talukdar > wrote: > >> Hi Barry, >> >> - In process_misc_ino_types(), dino->di_core.di_size is being accessed >> without being converted to machine format. The check is being >> performed against 0; so, it should be fine. But for better code >> readability, I guess it should be accessed through be64_to_cpu(). > > Yeah... sort of in two-minds about this one. > Well, traditionally we would not be endian converting it. We don't endian convert things which are compared to zero or are only 1 byte. There are a bunch of examples in the kernel code (many Christoph has done) and we should be consistent IMHO. (There is, of course, no point from a code point of view - I guess you might consider that you are letting people know that we need to endian convert this value in general and that if we change the code in the future it might be needed... but just say no.:) --Tim From owner-xfs@oss.sgi.com Tue Jan 15 20:59:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 21:00:20 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0G4xV2a010711 for ; Tue, 15 Jan 2008 20:59:34 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA26170; Wed, 16 Jan 2008 15:59:49 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0G4xkLF26602708; Wed, 16 Jan 2008 15:59:47 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0G4xhKD26479688; Wed, 16 Jan 2008 15:59:43 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 16 Jan 2008 15:59:43 +1100 From: David Chinner To: Timothy Shimmin Cc: Barry Naujok , Chandan Talukdar , "xfs@oss.sgi.com" Subject: Re: [REVIEW] Refactor xfs_repair's process_dinode_int Message-ID: <20080116045943.GU155407@sgi.com> References: <4782B72D.8070208@agami.com> <47833C0F.6070206@agami.com> <478D1899.9080201@agami.com> <478D75C2.5010004@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478D75C2.5010004@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14142 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Jan 16, 2008 at 02:10:58PM +1100, Timothy Shimmin wrote: > Not that it is a big deal....but my 2 cents... > > Barry Naujok wrote: > >On Wed, 16 Jan 2008 07:33:29 +1100, Chandan Talukdar > >wrote: > > > >>Hi Barry, > >> > >>- In process_misc_ino_types(), dino->di_core.di_size is being accessed > >>without being converted to machine format. The check is being > >>performed against 0; so, it should be fine. But for better code > >>readability, I guess it should be accessed through be64_to_cpu(). > > > >Yeah... sort of in two-minds about this one. > > > Well, traditionally we would not be endian converting it. > We don't endian convert things which are compared to zero or > are only 1 byte. There are a bunch of examples in the kernel > code (many Christoph has done) and we should be consistent IMHO. > > (There is, of course, no point from a code point of view - Exactly. As a result the kernel does not have endian types for single byte variables (ie. there's __be16, __be32, __be64 but not __be8), nor are there cpu_to_be8 or be8_to_cpu conversion functions. Hence the lack of them in the XFS code ;) > I guess you might consider that you are letting people know > that we need to endian convert this value in general and > that if we change the code in the future it might be needed... Well, that should be obvious when changing the structure that has lots of __beX types in already.... > but just say no.:) Agreed ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jan 15 22:32:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 22:33:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G6WuMq016898 for ; Tue, 15 Jan 2008 22:32:59 -0800 X-ASG-Debug-ID: 1200465191-52dd00650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B7468524A27 for ; Tue, 15 Jan 2008 22:33:11 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id c5MBFsBxIXx9a3tI for ; Tue, 15 Jan 2008 22:33:11 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JF1pD-0005Yo-4w; Wed, 16 Jan 2008 06:32:35 +0000 Date: Wed, 16 Jan 2008 06:32:35 +0000 From: Christoph Hellwig To: David Chinner Cc: Timothy Shimmin , Barry Naujok , Chandan Talukdar , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Refactor xfs_repair's process_dinode_int Subject: Re: [REVIEW] Refactor xfs_repair's process_dinode_int Message-ID: <20080116063234.GA21317@infradead.org> References: <4782B72D.8070208@agami.com> <47833C0F.6070206@agami.com> <478D1899.9080201@agami.com> <478D75C2.5010004@sgi.com> <20080116045943.GU155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080116045943.GU155407@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1200465194 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39656 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14143 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Jan 16, 2008 at 03:59:43PM +1100, David Chinner wrote: > As a result the kernel does not have endian types for single > byte variables (ie. there's __be16, __be32, __be64 but not __be8), > nor are there cpu_to_be8 or be8_to_cpu conversion functions. > Hence the lack of them in the XFS code ;) > > > I guess you might consider that you are letting people know > > that we need to endian convert this value in general and > > that if we change the code in the future it might be needed... > > Well, that should be obvious when changing the structure > that has lots of __beX types in already.... Actually enabling sparse checking for endianess annotations is still on my todo list. I started this project a while ago but failed when the cgcc wrapper had some problems interacting with libtool. I'll see how to get that resolved. From owner-xfs@oss.sgi.com Tue Jan 15 22:43:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 22:43:47 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G6hc0d017906 for ; Tue, 15 Jan 2008 22:43:42 -0800 X-ASG-Debug-ID: 1200465836-52dd007c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 368E8524DC0 for ; Tue, 15 Jan 2008 22:43:57 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by cuda.sgi.com with ESMTP id sfJ81nCx7R4icHm5 for ; Tue, 15 Jan 2008 22:43:57 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so256234waf.18 for ; Tue, 15 Jan 2008 22:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=2t3n6AQTQ+6Qcr+tj0+oiJOE5/nHBbKZP1p31BQ3Pvc=; b=uvk4sAhE+3ZlS875fjDPzpLLe78CjjQtG7RIDglUIewetJ4wWbizEFx/8onJZlNMuBK4t5gTNW+cxT1eVGCY0u4yF2r4NL4CYGc5GMbX1ToaUpmDKIgy+6ITOihtU6zYwPNzhwXF4LicKuehYU44eYhsznm4riKnz/a2DSzrIhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=RyHob+mqyaBcoZ4xsBNgRvDfMymfTT30xEZ0gOocnObQqWYeBSffW32/qE2uDprGqXHDWrfVYfbkWNekJEWI2s/m/x3wkm9V+t/aL+g5apomR1o4kMAG/s4czqm3WnE7XIFEr1Ku+jJJbun6TMmH/O2s9auItKz3B4l18lSi5xc= Received: by 10.114.12.9 with SMTP id 9mr525560wal.23.1200465834032; Tue, 15 Jan 2008 22:43:54 -0800 (PST) Received: by 10.114.182.4 with HTTP; Tue, 15 Jan 2008 22:43:54 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 12:13:54 +0530 From: "Gopala Krishna" To: nscott@aconex.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync Cc: xfs@oss.sgi.com In-Reply-To: <1200436012.9463.184.camel@edge.scott.net.au> MIME-Version: 1.0 References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.177] X-Barracuda-Start-Time: 1200465837 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39656 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1223 X-archive-position: 14144 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gopalakrishna.n.m@gmail.com Precedence: bulk X-list: xfs Is there any XFS call from user level to flush metadata for a given file or complete log to disk? Thanks, Gopal. On 1/16/08, Nathan Scott wrote: > > On Tue, 2008-01-15 at 09:18 -0600, Eric Sandeen wrote: > > > > > I have lot of code getting in to that. To explain that I have to go > > through > > > that complex part of the code to explain in detail. > > > > > > Basically once we get indoe number for a given file from the > > available > > > system call, we only depending upon the XFS layout and it's > > structure. We > > > are reading super block from a particular disk offset and > > calculating > > > address for inode offset and its address on the disk and reading > > directly > > > from the disk offset. We are totally depending on XFS on disk > > layout. > > > > Can I ask why you are doing this? :) > > > > This would be good to know. If you absolutely must use inode numbers > instead of path names, you should use the "by-handle" interface (like > xfsdump, xfs_fsr, etc) and not use the ondisk structures directly - > doing so is always "broken by design" and you'll get little sympathy > here for doing so. :) > > cheers. > > -- > Nathan > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jan 15 23:25:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 23:25:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_20,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G7P008020986 for ; Tue, 15 Jan 2008 23:25:04 -0800 X-ASG-Debug-ID: 1200468318-76a400860000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 83E44C5678D for ; Tue, 15 Jan 2008 23:25:18 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by cuda.sgi.com with ESMTP id R2c0oTmlMZZEADmt for ; Tue, 15 Jan 2008 23:25:18 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so276931waf.18 for ; Tue, 15 Jan 2008 23:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=JWuwTZzb5K2nZ0yPXxUwQ4Etx3ybq0XK2sGXJ4TUf4Q=; b=WQhmtrH7TDMKeYQBPsttByKOgIkPofuMWyLe8UnkhWOjhb/ZJZOzAEXY5oE08p9+ypW1+Zl6j8ObjnlaP9YZDZmldKEdnjJQBICI8giaiWnDepMCnxaxT6Upt43fZPk6BZ8bLtdehUP65YU5klZNATqKm2vwd9CE2zL5ig0gXyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=UQLy/70s4O/xFo7EcvLyCnRD+P3qHV6u4ui+Z6Ro4Ob2oGY5bzJ/lOnj+43yHb4g0LDykw2dVKhw9yG8Ld302w++EYLQX61kD/Decf+pVscC/D1aSUPFSDz1FjJrV1dTRyNbWyj9mRh9ZTGK8i2sDzUDJAJbSyVNV98LCbm1RS4= Received: by 10.115.74.1 with SMTP id b1mr536309wal.93.1200468317697; Tue, 15 Jan 2008 23:25:17 -0800 (PST) Received: by 10.114.182.4 with HTTP; Tue, 15 Jan 2008 23:25:17 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 12:55:17 +0530 From: "Gopala Krishna" To: "Chris Wedgwood" X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync Cc: nscott@aconex.com, xfs@oss.sgi.com In-Reply-To: <20080116064840.GA5725@puku.stupidest.org> MIME-Version: 1.0 References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> <20080116064840.GA5725@puku.stupidest.org> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.177] X-Barracuda-Start-Time: 1200468318 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39657 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1430 X-archive-position: 14145 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gopalakrishna.n.m@gmail.com Precedence: bulk X-list: xfs Thank you Chris. While replying to Eric, I mentioned why we are doing that. We are basically providing interfaces to back up applications in a pure storage environment that deals with the back up at block level (sector level) and hence depending upon different file system, we need to get information about file like it's extent information and associated block numbers etc. To extract these there is no system call and hence we are depending on disk layout published by file system vendors and the header file provided by them. If there is a user level system call to deal with the extent information etc, we can use , but many file system is not providing that. Basically if we give file it should eb in aposition to display metadata informations including extents and corresponding logical block numbers and device offsets. I have to do it programitically and hence if I have some system call rather than command, that would be helpful. Freeze/unfreeze is a command it seems right? Thanks, Gopal. On 1/16/08, Chris Wedgwood wrote: > > On Wed, Jan 16, 2008 at 12:13:54PM +0530, Gopala Krishna wrote: > > > Is there any XFS call from user level to flush metadata for a given > > file or complete log to disk? > > like a said earlier, try freeze/unfreeze > > you've not explained what you're doing (well, why you're doing it) > > it sounds very problematic by design > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jan 15 23:52:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 15 Jan 2008 23:52:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G7q2fX022717 for ; Tue, 15 Jan 2008 23:52:05 -0800 X-ASG-Debug-ID: 1200469939-14c502af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C9C2E525121 for ; Tue, 15 Jan 2008 23:52:20 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by cuda.sgi.com with ESMTP id DBXJw2NW3vNOECgi for ; Tue, 15 Jan 2008 23:52:20 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id e12so197659fga.8 for ; Tue, 15 Jan 2008 23:52:19 -0800 (PST) Received: by 10.86.60.15 with SMTP id i15mr455774fga.28.1200469938886; Tue, 15 Jan 2008 23:52:18 -0800 (PST) Received: from teal.hq.k1024.org ( [84.75.117.152]) by mx.google.com with ESMTPS id y6sm1418411mug.1.2008.01.15.23.52.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Jan 2008 23:52:17 -0800 (PST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 859F540A556; Wed, 16 Jan 2008 08:52:15 +0100 (CET) Date: Wed, 16 Jan 2008 08:52:15 +0100 From: Iustin Pop To: Gopala Krishna Cc: Chris Wedgwood , nscott@aconex.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync Message-ID: <20080116075215.GA26822@teal.hq.k1024.org> Mail-Followup-To: Gopala Krishna , Chris Wedgwood , nscott@aconex.com, xfs@oss.sgi.com References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> <20080116064840.GA5725@puku.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.154] X-Barracuda-Start-Time: 1200469940 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39657 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14146 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote: > If there is a user level system call to deal with the extent information > etc, we can use , but many file system is not providing that. Basically if > we give file it should eb in aposition to display metadata informations > including extents and corresponding logical block numbers and device > offsets. > > I have to do it programitically and hence if I have some system call rather > than command, that would be helpful. Freeze/unfreeze is a command it seems > right? Well, most commands are backed by a system call, right? For example, strace xfs_freeze to see what system calls it does. IIRC, only xfs_db has to access the raw device. For the block mapping, look at xfs_bmap (and its backend xfs_io), which should do exactly what you want. iustin From owner-xfs@oss.sgi.com Wed Jan 16 00:17:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 00:17:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G8HCAf026546 for ; Wed, 16 Jan 2008 00:17:14 -0800 X-ASG-Debug-ID: 1200471450-52dc01160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B42AB525284 for ; Wed, 16 Jan 2008 00:17:30 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by cuda.sgi.com with ESMTP id npJGVCXUbE0Q2EGm for ; Wed, 16 Jan 2008 00:17:30 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so304225waf.18 for ; Wed, 16 Jan 2008 00:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=CpCxPuucXBNQVov6eSWTFwx/YXH+8X7xYVVQ7vvIuAc=; b=MJEFxVfK1DoMTN385nNlELkRKetSucTK8Or9Lvow5f8ZaB/VF/OO3dptHsnuQw+EGfSQCEdcN24GpgIH3QmK+K5QBUfWgdic3r5lo37bMd6BPRBtCB+q+BdO9vz3vyRXLzvAUcOTntC2LAK2TT0WZ95f93aATI/vtDxtL9sRpKk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=sQWw9lXWwnjce95Zd8onLvduPzdPMSGLCx1kafsUHu/Xhot2Cikae/ulWoboUUQq8v8yjo2GTyMtwAKsyhi9xbHh4PDax4nBTYnnsFXtYOqvYzwYwm+/iY6ZZWpDHKi3mAw63IDaszCpFaBdnoWUFmhVD0Z1xd8OJnqZCRKoiMI= Received: by 10.114.123.1 with SMTP id v1mr560256wac.147.1200471077897; Wed, 16 Jan 2008 00:11:17 -0800 (PST) Received: by 10.114.182.4 with HTTP; Wed, 16 Jan 2008 00:11:17 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 13:41:17 +0530 From: "Gopala Krishna" To: "Gopala Krishna" , "Chris Wedgwood" , nscott@aconex.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync In-Reply-To: <20080116075215.GA26822@teal.hq.k1024.org> MIME-Version: 1.0 References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> <20080116064840.GA5725@puku.stupidest.org> <20080116075215.GA26822@teal.hq.k1024.org> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.178] X-Barracuda-Start-Time: 1200471450 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39657 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1058 X-archive-position: 14147 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gopalakrishna.n.m@gmail.com Precedence: bulk X-list: xfs You are right and that is the approach I will follow if there is no direct system call. Thanks, Gopal. On 1/16/08, Iustin Pop wrote: > > On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote: > > If there is a user level system call to deal with the extent information > > etc, we can use , but many file system is not providing that. Basically > if > > we give file it should eb in aposition to display metadata informations > > including extents and corresponding logical block numbers and device > > offsets. > > > > I have to do it programitically and hence if I have some system call > rather > > than command, that would be helpful. Freeze/unfreeze is a command it > seems > > right? > > Well, most commands are backed by a system call, right? For example, > strace xfs_freeze to see what system calls it does. IIRC, only xfs_db > has to access the raw device. > > For the block mapping, look at xfs_bmap (and its backend xfs_io), which > should do exactly what you want. > > iustin > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Jan 16 00:25:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 00:25:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G8PM17031416 for ; Wed, 16 Jan 2008 00:25:23 -0800 X-ASG-Debug-ID: 1200471940-78e000df0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 719CF525318 for ; Wed, 16 Jan 2008 00:25:40 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id DHQZb2AbvRHIFGna for ; Wed, 16 Jan 2008 00:25:40 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JF3a2-0006Jv-Vj; Wed, 16 Jan 2008 08:25:03 +0000 Date: Wed, 16 Jan 2008 08:25:02 +0000 From: Christoph Hellwig To: Gopala Krishna Cc: Chris Wedgwood , nscott@aconex.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync Message-ID: <20080116082502.GA24175@infradead.org> References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> <20080116064840.GA5725@puku.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1200471941 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39657 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14148 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote: > While replying to Eric, I mentioned why we are doing that. We are > basically providing interfaces to back up applications in a pure storage > environment that deals with the back up at block level (sector level) and > hence depending upon different file system, we need to get information about > file like it's extent information and associated block numbers etc. This basically can't work. If you do a plain block based backup you need to freeze the filesystem first and then either backup through a newly created snapshot or the raw device. Alternatively you can do file-based backups assisted by the bulkstat interface as done by xfsdump. If you try to mix the two layers you get into deep trouble due to various issues: - knowledge of the disk format. The ondisk format can change anytime and will break your application. And yes, additions to the ondisk format do happen quite frequently. - no coherency between the filesystem and the block device node. This is especially true for backup applications which use the buffered block device nodes because there is a real-life chance that stale cache is around - no guarantee that the ondisk image is actually update. XFS like most other current filesystems uses an intent log to provide reliabily and sync is only guaranteed to push updates into the log but not actually write it back to it's "normal" location on disk. In short what you're trying to do is a road to disaster, so don't do it! Note that the problems apply to any filesystem in one way or another, not just XFS. From owner-xfs@oss.sgi.com Wed Jan 16 01:00:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 01:00:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0G900dO001159 for ; Wed, 16 Jan 2008 01:00:04 -0800 X-ASG-Debug-ID: 1200474015-53b401e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 359A7C569E8 for ; Wed, 16 Jan 2008 01:00:15 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by cuda.sgi.com with ESMTP id aSZ0cEnhPAFml6Z6 for ; Wed, 16 Jan 2008 01:00:15 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so327787waf.18 for ; Wed, 16 Jan 2008 01:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=q4/XuHgR6btpig686N/WD+ql5Hi/FGHyaR3hUUfmo/s=; b=TzWcBo58L8SmKA6hXi7wOaqALZ1uRr1/LhdsbLEFdmP3eIR9KcGqDXCUnIgE2K9JyQzv1uBhQE2BorzHy9RDq9tG7/KK/yqwFHUnmiovsD4YL44VBTMZECgAqY2HY6KAR1SgQ51leo8O3Jn8BJBfE8UnJNoOlOwX5VS9xOEDRAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=FNtH0qVGg/5WNncDqDyIXu+Sh8vRIGnc5iGTfNAKpcLM8dt9bhGLJjomls5FT+VlP6vKYgBd3gko/dBq5pEyBx4TcXbpVR2L7AILK8a/Fez3HZeo+3hdFsc+Ow3lM7SBm3xMvFM8odkly8gRZeYpjuGAae7MNDo1+BNcMc6T/8c= Received: by 10.114.110.12 with SMTP id i12mr636229wac.73.1200474014809; Wed, 16 Jan 2008 01:00:14 -0800 (PST) Received: by 10.114.182.4 with HTTP; Wed, 16 Jan 2008 01:00:14 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 14:30:14 +0530 From: "Gopala Krishna" To: "Christoph Hellwig" X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync Cc: "Chris Wedgwood" , nscott@aconex.com, xfs@oss.sgi.com In-Reply-To: <20080116082502.GA24175@infradead.org> MIME-Version: 1.0 References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> <20080116064840.GA5725@puku.stupidest.org> <20080116082502.GA24175@infradead.org> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.178] X-Barracuda-Start-Time: 1200474018 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39658 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1947 X-archive-position: 14149 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gopalakrishna.n.m@gmail.com Precedence: bulk X-list: xfs Thanks for the suggestions!. I will relook at the my idea and design....implemetation. As of now what we are doing is in experimental stage. Thanks, Gopal. On 1/16/08, Christoph Hellwig wrote: > > On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote: > > While replying to Eric, I mentioned why we are doing that. We are > > basically providing interfaces to back up applications in a pure storage > > environment that deals with the back up at block level (sector level) > and > > hence depending upon different file system, we need to get information > about > > file like it's extent information and associated block numbers etc. > > This basically can't work. If you do a plain block based backup you > need to freeze the filesystem first and then either backup through a > newly created snapshot or the raw device. Alternatively you can do > file-based backups assisted by the bulkstat interface as done by > xfsdump. If you try to mix the two layers you get into deep trouble > due to various issues: > > - knowledge of the disk format. The ondisk format can change anytime > and will break your application. And yes, additions to the ondisk > format do happen quite frequently. > - no coherency between the filesystem and the block device node. This > is especially true for backup applications which use the buffered > block device nodes because there is a real-life chance that stale > cache is around > - no guarantee that the ondisk image is actually update. XFS like > most other current filesystems uses an intent log to provide > reliabily and sync is only guaranteed to push updates into the log > but not actually write it back to it's "normal" location on disk. > > In short what you're trying to do is a road to disaster, so don't do it! > > Note that the problems apply to any filesystem in one way or another, > not just XFS. > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Jan 16 03:52:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 03:52:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0GBqDm9013510 for ; Wed, 16 Jan 2008 03:52:17 -0800 Received: from [134.15.251.7] (melb-sw-corp-251-7.corp.sgi.com [134.15.251.7]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA08131; Wed, 16 Jan 2008 22:52:19 +1100 Message-ID: <478DEFF0.40004@sgi.com> Date: Wed, 16 Jan 2008 22:52:16 +1100 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Gopala Krishna CC: Christoph Hellwig , Chris Wedgwood , nscott@aconex.com, xfs@oss.sgi.com Subject: Re: Question related to XFS sync , especially fsync References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> <20080116064840.GA5725@puku.stupidest.org> <20080116082502.GA24175@infradead.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5484/Tue Jan 15 11:31:27 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14150 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Gopala, it sounds like you want something like NDMP. Check that out first. -- Mark Gopala Krishna wrote: > Thanks for the suggestions!. I will relook at the my idea and > design....implemetation. As of now what we are doing is in experimental > stage. > > Thanks, > Gopal. > > > On 1/16/08, Christoph Hellwig wrote: >> On Wed, Jan 16, 2008 at 12:55:17PM +0530, Gopala Krishna wrote: >>> While replying to Eric, I mentioned why we are doing that. We are >>> basically providing interfaces to back up applications in a pure storage >>> environment that deals with the back up at block level (sector level) >> and >>> hence depending upon different file system, we need to get information >> about >>> file like it's extent information and associated block numbers etc. >> This basically can't work. If you do a plain block based backup you >> need to freeze the filesystem first and then either backup through a >> newly created snapshot or the raw device. Alternatively you can do >> file-based backups assisted by the bulkstat interface as done by >> xfsdump. If you try to mix the two layers you get into deep trouble >> due to various issues: >> >> - knowledge of the disk format. The ondisk format can change anytime >> and will break your application. And yes, additions to the ondisk >> format do happen quite frequently. >> - no coherency between the filesystem and the block device node. This >> is especially true for backup applications which use the buffered >> block device nodes because there is a real-life chance that stale >> cache is around >> - no guarantee that the ondisk image is actually update. XFS like >> most other current filesystems uses an intent log to provide >> reliabily and sync is only guaranteed to push updates into the log >> but not actually write it back to it's "normal" location on disk. >> >> In short what you're trying to do is a road to disaster, so don't do it! >> >> Note that the problems apply to any filesystem in one way or another, >> not just XFS. >> >> > > > [[HTML alternate version deleted]] > > -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Jan 16 10:02:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 10:02:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_56 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0GI2MV0013197 for ; Wed, 16 Jan 2008 10:02:24 -0800 X-ASG-Debug-ID: 1200506560-5a18005d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 67551527FDC for ; Wed, 16 Jan 2008 10:02:41 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id lM5DCpYN5q3XyOtq for ; Wed, 16 Jan 2008 10:02:41 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 5C33C1C000266; Wed, 16 Jan 2008 13:02:40 -0500 (EST) Date: Wed, 16 Jan 2008 13:02:40 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Al Boldi cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org, Alan Piszcz X-ASG-Orig-Subj: Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again Subject: Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again In-Reply-To: <200801162027.00791.a1426z@gawab.com> Message-ID: References: <200801162027.00791.a1426z@gawab.com> User-Agent: Alpine 0.999999 (DEB 847 2007-12-06) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1200506561 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39680 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5485/Wed Jan 16 05:06:29 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14151 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Wed, 16 Jan 2008, Al Boldi wrote: > Justin Piszcz wrote: >> For these benchmarks I timed how long it takes to extract a standard 4.4 >> GiB DVD: >> >> Settings: Software RAID 5 with the following settings (until I change >> those too): >> >> Base setup: >> blockdev --setra 65536 /dev/md3 >> echo 16384 > /sys/block/md3/md/stripe_cache_size >> echo "Disabling NCQ on all disks..." >> for i in $DISKS >> do >> echo "Disabling NCQ on $i" >> echo 1 > /sys/block/"$i"/device/queue_depth >> done >> >> p34:~# grep : *chunk* |sort -n >> 4-chunk.txt:0:45.31 >> 8-chunk.txt:0:44.32 >> 16-chunk.txt:0:41.02 >> 32-chunk.txt:0:40.50 >> 64-chunk.txt:0:40.88 >> 128-chunk.txt:0:40.21 >> 256-chunk.txt:0:40.14*** >> 512-chunk.txt:0:40.35 >> 1024-chunk.txt:0:41.11 >> 2048-chunk.txt:0:43.89 >> 4096-chunk.txt:0:47.34 >> 8192-chunk.txt:0:57.86 >> 16384-chunk.txt:1:09.39 >> 32768-chunk.txt:1:26.61 >> >> It would appear a 256 KiB chunk-size is optimal. > > Can you retest with different max_sectors_kb on both md and sd? Remember this is SW RAID, so max_sectors_kb will only affect the individual disks underneath the SW RAID, I have benchmarked in the past, the defaults chosen by the kernel are optimal, changing them did not make any noticable improvements. > > Also, can you retest using dd with different block-sizes? I can do this, moment.. I know about oflag=direct but I choose to use dd with sync and measure the total time it takes. /usr/bin/time -f %E -o ~/$i=chunk.txt bash -c 'dd if=/dev/zero of=/r1/bigfile bs=1M count=10240; sync' So I was asked on the mailing list to test dd with various chunk sizes, here is the length of time it took to write 10 GiB and sync per each chunk size: 4=chunk.txt:0:25.46 8=chunk.txt:0:25.63 16=chunk.txt:0:25.26 32=chunk.txt:0:25.08 64=chunk.txt:0:25.55 128=chunk.txt:0:25.26 256=chunk.txt:0:24.72 512=chunk.txt:0:24.71 1024=chunk.txt:0:25.40 2048=chunk.txt:0:25.71 4096=chunk.txt:0:27.18 8192=chunk.txt:0:29.00 16384=chunk.txt:0:31.43 32768=chunk.txt:0:50.11 65536=chunk.txt:2:20.80 Justin. From owner-xfs@oss.sgi.com Wed Jan 16 10:19:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 10:19:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0GIJcKx014629 for ; Wed, 16 Jan 2008 10:19:40 -0800 X-ASG-Debug-ID: 1200507593-17c100970000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 26922C6078E for ; Wed, 16 Jan 2008 10:19:53 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id lHZfwhw5gl5jMXPR for ; Wed, 16 Jan 2008 10:19:53 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 6B9DF1C000266; Wed, 16 Jan 2008 13:19:53 -0500 (EST) Date: Wed, 16 Jan 2008 13:19:53 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Greg Cormier cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org, Alan Piszcz X-ASG-Orig-Subj: Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again Subject: Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again In-Reply-To: <29a863790801161009h7bb1f0f7v34bc893fce338567@mail.gmail.com> Message-ID: References: <29a863790801161009h7bb1f0f7v34bc893fce338567@mail.gmail.com> User-Agent: Alpine 0.999999 (DEB 847 2007-12-06) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1200507597 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39681 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5485/Wed Jan 16 05:06:29 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14152 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Wed, 16 Jan 2008, Greg Cormier wrote: > What sort of tools are you using to get these benchmarks, and can I > used them for ext3? > > Very interested in running this on my server. > > > Thanks, > Greg > You can use whatever suits you, such as untar kernel source tree, copy files, untar backups, etc--, you should benchmark specifically what *your* workload is. Here is the skeleton, using bash:: (don't forget to turn off the cron daemon) for i in 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 do cd / umount /r1 mdadm -S /dev/md3 mdadm --create --assume-clean --verbose /dev/md3 --level=5 --raid-devices=10 --chunk=$i --run /dev/sd[c-l]1 /etc/init.d/oraid.sh # to optimize my raid stuff mkfs.xfs -f /dev/md3 mount /dev/md3 /r1 -o logbufs=8,logbsize=262144 # then simply add what you do often here # everyone's workload is different /usr/bin/time -f %E -o ~/$i=chunk.txt bash -c 'dd if=/dev/zero of=/r1/bigfile bs=1M count=10240; sync' done Then just, grep : /root/*chunk* | sort -n to get the results in the same format. Justin. From owner-xfs@oss.sgi.com Wed Jan 16 13:17:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 13:17:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0GLHObJ002364 for ; Wed, 16 Jan 2008 13:17:25 -0800 X-ASG-Debug-ID: 1200518259-014300400000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 80ACBC676DB for ; Wed, 16 Jan 2008 13:17:39 -0800 (PST) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id IAiUlFGtcokag4Mu for ; Wed, 16 Jan 2008 13:17:39 -0800 (PST) Received: from [192.168.1.21] (dslb-084-057-098-078.pools.arcor-ip.net [84.57.98.78]) by mail.lichtvoll.de (Postfix) with ESMTP id DDDB85AE2F; Wed, 16 Jan 2008 22:16:52 +0100 (CET) From: Martin Steigerwald To: markgw@sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync Date: Wed, 16 Jan 2008 22:17:34 +0100 User-Agent: KMail/1.9.7 Cc: Gopala Krishna , Christoph Hellwig , Chris Wedgwood , nscott@aconex.com, xfs@oss.sgi.com References: <478DEFF0.40004@sgi.com> (sfid-20080116_130938_790120_481702E4) In-Reply-To: <478DEFF0.40004@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801162217.35594.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1200518262 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39693 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14153 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Am Mittwoch 16 Januar 2008 schrieb Mark Goodwin: > Gopala, > > it sounds like you want something like NDMP. Check that out first. Is there an open source implementation available for this protocol? Would be interesting to know. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Wed Jan 16 14:52:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 14:52:53 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_56 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0GMqn1E008804 for ; Wed, 16 Jan 2008 14:52:50 -0800 X-ASG-Debug-ID: 1200523985-62f700d30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 03D42529F50 for ; Wed, 16 Jan 2008 14:53:06 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id FzQkZ4MGPnnZ7nDE for ; Wed, 16 Jan 2008 14:53:06 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 4DA511C00022E; Wed, 16 Jan 2008 17:53:05 -0500 (EST) Date: Wed, 16 Jan 2008 17:53:05 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Al Boldi cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org, Alan Piszcz X-ASG-Orig-Subj: Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again Subject: Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again In-Reply-To: <200801170019.04836.a1426z@gawab.com> Message-ID: References: <200801162027.00791.a1426z@gawab.com> <200801170019.04836.a1426z@gawab.com> User-Agent: Alpine 0.999999 (DEB 847 2007-12-06) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1200523988 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39696 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14154 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Thu, 17 Jan 2008, Al Boldi wrote: > Justin Piszcz wrote: >> On Wed, 16 Jan 2008, Al Boldi wrote: >>>> Also, can you retest using dd with different block-sizes? >> >> I can do this, moment.. >> >> >> I know about oflag=direct but I choose to use dd with sync and measure the >> total time it takes. >> /usr/bin/time -f %E -o ~/$i=chunk.txt bash -c 'dd if=/dev/zero >> of=/r1/bigfile bs=1M count=10240; sync' >> >> So I was asked on the mailing list to test dd with various chunk sizes, >> here is the length of time it took >> to write 10 GiB and sync per each chunk size: >> >> 4=chunk.txt:0:25.46 >> 8=chunk.txt:0:25.63 >> 16=chunk.txt:0:25.26 >> 32=chunk.txt:0:25.08 >> 64=chunk.txt:0:25.55 >> 128=chunk.txt:0:25.26 >> 256=chunk.txt:0:24.72 >> 512=chunk.txt:0:24.71 >> 1024=chunk.txt:0:25.40 >> 2048=chunk.txt:0:25.71 >> 4096=chunk.txt:0:27.18 >> 8192=chunk.txt:0:29.00 >> 16384=chunk.txt:0:31.43 >> 32768=chunk.txt:0:50.11 >> 65536=chunk.txt:2:20.80 > > What do you get with bs=512,1k,2k,4k,8k,16k... > > > Thanks! > > -- > Al > > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Done testing for now, but I did test with 256k with a 256k chunk and obviously that got good results, just like 1m with a 1mb chunk, 460-480 MiB/s. Justin. From owner-xfs@oss.sgi.com Wed Jan 16 14:55:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 14:55:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_56 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0GMtD1x009163 for ; Wed, 16 Jan 2008 14:55:17 -0800 X-ASG-Debug-ID: 1200524131-4c7500930000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 07CD8C68CDB for ; Wed, 16 Jan 2008 14:55:31 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id m5CpVxSARcLbn6TD for ; Wed, 16 Jan 2008 14:55:31 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id D5FA31C000238; Wed, 16 Jan 2008 17:55:00 -0500 (EST) Date: Wed, 16 Jan 2008 17:55:00 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Al Boldi cc: xfs@oss.sgi.com, linux-raid@vger.kernel.org, Alan Piszcz X-ASG-Orig-Subj: Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again Subject: Re: Linux Software RAID 5 + XFS Multi-Benchmarks / 10 Raptors Again In-Reply-To: <200801170019.04836.a1426z@gawab.com> Message-ID: References: <200801162027.00791.a1426z@gawab.com> <200801170019.04836.a1426z@gawab.com> User-Agent: Alpine 0.999999 (DEB 847 2007-12-06) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1200524132 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39697 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14155 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Thu, 17 Jan 2008, Al Boldi wrote: > Justin Piszcz wrote: >> On Wed, 16 Jan 2008, Al Boldi wrote: >>>> Also, can you retest using dd with different block-sizes? >> >> I can do this, moment.. >> >> >> I know about oflag=direct but I choose to use dd with sync and measure the >> total time it takes. >> /usr/bin/time -f %E -o ~/$i=chunk.txt bash -c 'dd if=/dev/zero >> of=/r1/bigfile bs=1M count=10240; sync' >> >> So I was asked on the mailing list to test dd with various chunk sizes, >> here is the length of time it took >> to write 10 GiB and sync per each chunk size: >> >> 4=chunk.txt:0:25.46 >> 8=chunk.txt:0:25.63 >> 16=chunk.txt:0:25.26 >> 32=chunk.txt:0:25.08 >> 64=chunk.txt:0:25.55 >> 128=chunk.txt:0:25.26 >> 256=chunk.txt:0:24.72 >> 512=chunk.txt:0:24.71 >> 1024=chunk.txt:0:25.40 >> 2048=chunk.txt:0:25.71 >> 4096=chunk.txt:0:27.18 >> 8192=chunk.txt:0:29.00 >> 16384=chunk.txt:0:31.43 >> 32768=chunk.txt:0:50.11 >> 65536=chunk.txt:2:20.80 > > What do you get with bs=512,1k,2k,4k,8k,16k... > > > Thanks! > > -- > Al > > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > root 4621 0.0 0.0 12404 760 pts/2 D+ 17:53 0:00 mdadm -S /dev/md3 root 4664 0.0 0.0 4264 728 pts/5 S+ 17:54 0:00 grep D Tried to stop it when it was re-syncing, DEADLOCK :( [ 305.464904] md: md3 still in use. [ 314.595281] md: md_do_sync() got signal ... exiting Anyhow, done testing, time to move data back on if I can kill the resync process w/out deadlock. Justin. From owner-xfs@oss.sgi.com Wed Jan 16 15:24:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 15:24:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0GNOlgr011912 for ; Wed, 16 Jan 2008 15:24:49 -0800 X-ASG-Debug-ID: 1200525904-4c7500dc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.purevideo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7FF72C6920A for ; Wed, 16 Jan 2008 15:25:04 -0800 (PST) Received: from mail.purevideo.com (mail.purevideo.com [208.50.29.149]) by cuda.sgi.com with ESMTP id 4dQgQNU1I11IWCck for ; Wed, 16 Jan 2008 15:25:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: Repairing a possibly incomplete xfs_growfs command? Subject: Repairing a possibly incomplete xfs_growfs command? Date: Wed, 16 Jan 2008 15:19:19 -0800 Message-ID: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Repairing a possibly incomplete xfs_growfs command? Thread-Index: AchYl2UPy/3V5aeGTG6WxLQ5nlhTOA== From: "Mark Magpayo" To: X-Barracuda-Connect: mail.purevideo.com[208.50.29.149] X-Barracuda-Start-Time: 1200525905 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39697 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m0GNOngr011915 X-archive-position: 14156 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmagpayo@purevideo.com Precedence: bulk X-list: xfs Hi, So I have run across a strange situation which I hope there are some gurus out there to help. The original setup was a logical volume of 8.9TB. I extended the volume to 17.7TB and attempted to run xfs_growfs. I am not sure whether the command actually finished, as after I ran the command, the metadata was displayed, but there was no nothing that stated the the number of data blocks had changed. I was just returned to the prompt, so I'm not sure whether the command completed or not.. I was unable write to the logical volume I had just created. I tried to remount it, but I kept getting an error saying the superblock could not be read. I tried running an xfs_repair on the filesystem, and get the following: Phase 1 - find and verify superblock... superblock read failed, offset 19504058859520, size 2048, ag 64, rval 0 fatal error -- Invalid argument I am not very experienced with xfs (I was following commands in some documentaion), and I was recommended to post to this mailing list. If anyone could provide some help, it would be greatly appreciate. Also, if there is any information I can provide to help, I will gladly provide it. Thanks in advance! Sincerely, Mark From owner-xfs@oss.sgi.com Wed Jan 16 15:38:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 15:38:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0GNc3Vo013047 for ; Wed, 16 Jan 2008 15:38:07 -0800 Received: from [134.14.55.21] (dhcp21.melbourne.sgi.com [134.14.55.21]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26943; Thu, 17 Jan 2008 10:38:10 +1100 Message-ID: <478E955F.9080607@sgi.com> Date: Thu, 17 Jan 2008 10:38:07 +1100 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Martin Steigerwald CC: Gopala Krishna , Christoph Hellwig , Chris Wedgwood , nscott@aconex.com, xfs@oss.sgi.com Subject: Re: Question related to XFS sync , especially fsync References: <478DEFF0.40004@sgi.com> (sfid-20080116_130938_790120_481702E4) <200801162217.35594.Martin@lichtvoll.de> In-Reply-To: <200801162217.35594.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14157 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Martin Steigerwald wrote: > Am Mittwoch 16 Januar 2008 schrieb Mark Goodwin: >> Gopala, >> >> it sounds like you want something like NDMP. Check that out first. > > Is there an open source implementation available for this protocol? Would > be interesting to know. See http://www.ndmp.org for the FAQ, spec, etc. THere is a download area with an SDK but no open source version that I know of. Perhaps a new project is born ;-) Cheers -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Jan 16 17:24:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 17:24:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0H1Oihx023901 for ; Wed, 16 Jan 2008 17:24:46 -0800 X-ASG-Debug-ID: 1200533102-766200010000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.suse.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2684E52A922 for ; Wed, 16 Jan 2008 17:25:02 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id sEIKgIYnETQ9CRfD for ; Wed, 16 Jan 2008 17:25:02 -0800 (PST) X-ASG-Whitelist: Client Received: from Relay1.suse.de (relay-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 48EB32F839; Thu, 17 Jan 2008 02:25:00 +0100 (CET) To: "Gopala Krishna" Cc: "Chris Wedgwood" , nscott@aconex.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Question related to XFS sync , especially fsync Subject: Re: Question related to XFS sync , especially fsync From: Andi Kleen References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> <20080116064840.GA5725@puku.stupidest.org> Date: Thu, 17 Jan 2008 02:25:00 +0100 In-Reply-To: (Gopala Krishna's message of "Wed\, 16 Jan 2008 12\:55\:17 +0530") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Barracuda-Connect: mx2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1200533103 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14158 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs "Gopala Krishna" writes: > we need to get information about > file like it's extent information and associated block numbers etc. To > extract these there is no system call Actually there is the FIOBMAP ioctl for data blocks. e.g. it's used by boot loaders like lilo to create a block map to read a file without knowledge of the file system. Should work on all file systems that support lilo. It won't give you information about metadata blocks though. -Andi From owner-xfs@oss.sgi.com Wed Jan 16 18:30:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 18:31:03 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0H2UpIi027251 for ; Wed, 16 Jan 2008 18:30:53 -0800 X-ASG-Debug-ID: 1200537069-325c00700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 57207C6CBB0 for ; Wed, 16 Jan 2008 18:31:10 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 8RnBLOPylkEyXepf for ; Wed, 16 Jan 2008 18:31:10 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 58F3B18D90764; Wed, 16 Jan 2008 20:31:08 -0600 (CST) Message-ID: <478EBDEC.2070305@sandeen.net> Date: Wed, 16 Jan 2008 20:31:08 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mark Magpayo CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Repairing a possibly incomplete xfs_growfs command? Subject: Re: Repairing a possibly incomplete xfs_growfs command? References: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> In-Reply-To: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1200537070 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39701 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14159 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Magpayo wrote: > Hi, > > So I have run across a strange situation which I hope there are some > gurus out there to help. > > The original setup was a logical volume of 8.9TB. I extended the volume > to 17.7TB and attempted to run xfs_growfs. I am not sure whether the > command actually finished, as after I ran the command, the metadata was > displayed, but there was no nothing that stated the the number of data > blocks had changed. I was just returned to the prompt, so I'm not sure > whether the command completed or not.. > > I was unable write to the logical volume I had just created. I tried to > remount it, but I kept getting an error saying the superblock could not > be read. I tried running an xfs_repair on the filesystem, and get the > following: > > Phase 1 - find and verify superblock... > superblock read failed, offset 19504058859520, size 2048, ag 64, rval 0 > > fatal error -- Invalid argument hm, how big is your block device for starters - look in /proc/partitions. -Eric From owner-xfs@oss.sgi.com Wed Jan 16 18:44:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 18:44:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0H2ibOr028557 for ; Wed, 16 Jan 2008 18:44:39 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01222; Thu, 17 Jan 2008 13:44:52 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0H2inLF27715953; Thu, 17 Jan 2008 13:44:50 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0H2ih8s27721251; Thu, 17 Jan 2008 13:44:43 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 17 Jan 2008 13:44:43 +1100 From: David Chinner To: Andi Kleen Cc: Gopala Krishna , Chris Wedgwood , nscott@aconex.com, xfs@oss.sgi.com Subject: Re: Question related to XFS sync , especially fsync Message-ID: <20080117024443.GG155259@sgi.com> References: <20080114224245.GT155259@sgi.com> <478CCEAC.9010008@sandeen.net> <1200436012.9463.184.camel@edge.scott.net.au> <20080116064840.GA5725@puku.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14160 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Jan 17, 2008 at 02:25:00AM +0100, Andi Kleen wrote: > "Gopala Krishna" writes: > > > we need to get information about > > file like it's extent information and associated block numbers etc. > To > > extract these there is no system call > > Actually there is the FIOBMAP ioctl for data blocks. e.g. it's used by > boot loaders like lilo to create a block map to read a file without > knowledge of the file system. Should work on all file systems that > support lilo. On XFS, you should use XFS_IOC_GETBMAPX. It's much faster and returns lots more information than FIOBMAP. It can also be used on the attribute fork of the inode, and it works on directories as well. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Jan 16 19:01:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 16 Jan 2008 19:01:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0H311Hw030158 for ; Wed, 16 Jan 2008 19:01:03 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01636; Thu, 17 Jan 2008 14:01:15 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0H31DLF27661237; Thu, 17 Jan 2008 14:01:14 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0H31BA627713276; Thu, 17 Jan 2008 14:01:11 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 17 Jan 2008 14:01:11 +1100 From: David Chinner To: Mark Magpayo Cc: xfs@oss.sgi.com Subject: Re: Repairing a possibly incomplete xfs_growfs command? Message-ID: <20080117030111.GH155259@sgi.com> References: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5488/Wed Jan 16 12:44:30 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14161 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Jan 16, 2008 at 03:19:19PM -0800, Mark Magpayo wrote: > Hi, > > So I have run across a strange situation which I hope there are some > gurus out there to help. > > The original setup was a logical volume of 8.9TB. I extended the volume > to 17.7TB and attempted to run xfs_growfs. I am not sure whether the > command actually finished, as after I ran the command, the metadata was > displayed, but there was no nothing that stated the the number of data > blocks had changed. I was just returned to the prompt, so I'm not sure > whether the command completed or not.. Hmmm - what kernel and what version of xfsprogs are you using? (xfs_growfs -V). Also, can you post the output of the growfs command if you still have it? If not, the output of: # xfs_db -r -c 'sb 0' -c p # xfs_db -r -c 'sb 1' -c p because: > I was unable write to the logical volume I had just created. I tried to > remount it, but I kept getting an error saying the superblock could not > be read. I tried running an xfs_repair on the filesystem, and get the > following: > > Phase 1 - find and verify superblock... > superblock read failed, offset 19504058859520, size 2048, ag 64, rval 0 That's a weird size for a superblock, and I suspect you should only have AG's numbered 0-63 in your filesystem. (a 8.9TB filesystem will have 32 AGs (0-31) by default, and doubling the size will take it up to 64). > I am not very experienced with xfs (I was following commands in some > documentaion), and I was recommended to post to this mailing list. If > anyone could provide some help, it would be greatly appreciate. Also, > if there is any information I can provide to help, I will gladly provide > it. Thanks in advance! Seeing as the filesystem has not mounted, I think this should be recoverable if you don't try to mount or write anything to the filesystem until we fix the geometry back up.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jan 17 09:34:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 09:34:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0HHYQPA016435 for ; Thu, 17 Jan 2008 09:34:26 -0800 X-ASG-Debug-ID: 1200591281-370701380000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.purevideo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A55F3C71EFC for ; Thu, 17 Jan 2008 09:34:41 -0800 (PST) Received: from mail.purevideo.com (mail.purevideo.com [208.50.29.149]) by cuda.sgi.com with ESMTP id O9pGFzzRYD2mlNwG for ; Thu, 17 Jan 2008 09:34:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: RE: Repairing a possibly incomplete xfs_growfs command? Subject: RE: Repairing a possibly incomplete xfs_growfs command? Date: Thu, 17 Jan 2008 09:29:22 -0800 Message-ID: <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> In-Reply-To: <20080117030111.GH155259@sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Repairing a possibly incomplete xfs_growfs command? Thread-Index: AchYtI4MxpSafxUdTpibUA+qJF4k8QAeloBw References: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> <20080117030111.GH155259@sgi.com> From: "Mark Magpayo" To: "David Chinner" Cc: X-Barracuda-Connect: mail.purevideo.com[208.50.29.149] X-Barracuda-Start-Time: 1200591284 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39714 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5491/Thu Jan 17 07:13:54 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m0HHYRPA016438 X-archive-position: 14162 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmagpayo@purevideo.com Precedence: bulk X-list: xfs > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf Of > David Chinner > Sent: Wednesday, January 16, 2008 7:01 PM > To: Mark Magpayo > Cc: xfs@oss.sgi.com > Subject: Re: Repairing a possibly incomplete xfs_growfs command? > > On Wed, Jan 16, 2008 at 03:19:19PM -0800, Mark Magpayo wrote: > > Hi, > > > > So I have run across a strange situation which I hope there are some > > gurus out there to help. > > > > The original setup was a logical volume of 8.9TB. I extended the volume > > to 17.7TB and attempted to run xfs_growfs. I am not sure whether the > > command actually finished, as after I ran the command, the metadata was > > displayed, but there was no nothing that stated the the number of data > > blocks had changed. I was just returned to the prompt, so I'm not sure > > whether the command completed or not.. > > Hmmm - what kernel and what version of xfsprogs are you using? > (xfs_growfs -V). > xfs_growfs version 2.9.4 > Also, can you post the output of the growfs command if you still > have it? > > If not, the output of: > > # xfs_db -r -c 'sb 0' -c p #xfs_db -r -c 'sb 0' -c p /dev/vg0/lv0 magicnum = 0x58465342 blocksize = 4096 dblocks = 11904332800 rblocks = 0 rextents = 0 uuid = 05d4f6ba-1e9c-4564-898b-98088c163fe1 logstart = 2147483652 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 74402080 agcount = 160 rbmblocks = 0 logblocks = 32768 versionnum = 0x3094 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 = 27 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 1335040 ifree = 55 fdblocks = 9525955616 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 > # xfs_db -r -c 'sb 1' -c p > #xfs_db -r -c 'sb 1' -c p /dev/vg0/lv0 magicnum = 0x58465342 blocksize = 4096 dblocks = 2380866560 rblocks = 0 rextents = 0 uuid = 05d4f6ba-1e9c-4564-898b-98088c163fe1 logstart = 2147483652 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 74402080 agcount = 32 rbmblocks = 0 logblocks = 32768 versionnum = 0x3094 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 = 27 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 1334912 ifree = 59 fdblocks = 2809815 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 > because: > > > I was unable write to the logical volume I had just created. I tried to > > remount it, but I kept getting an error saying the superblock could not > > be read. I tried running an xfs_repair on the filesystem, and get the > > following: > > > > Phase 1 - find and verify superblock... > > superblock read failed, offset 19504058859520, size 2048, ag 64, rval 0 > > That's a weird size for a superblock, and I suspect you should only > have AG's numbered 0-63 in your filesystem. (a 8.9TB filesystem will > have 32 AGs (0-31) by default, and doubling the size will take it > up to 64). > > > I am not very experienced with xfs (I was following commands in some > > documentaion), and I was recommended to post to this mailing list. If > > anyone could provide some help, it would be greatly appreciate. Also, > > if there is any information I can provide to help, I will gladly provide > > it. Thanks in advance! > > Seeing as the filesystem has not mounted, I think this should be > recoverable if you don't try to mount or write anything to the > filesystem until we fix the geometry back up.... > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > Someone else asked for the size of the block devices... here's the output from /proc/partitions: 152 0 9523468862 etherd/e1.0 152 16 9523468862 etherd/e0.0 I appreciate everyone's help! Thanks, Mark From owner-xfs@oss.sgi.com Thu Jan 17 12:08:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 12:08:49 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0HK8hdj030752 for ; Thu, 17 Jan 2008 12:08:45 -0800 X-ASG-Debug-ID: 1200600538-734701700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4FEA052F78B for ; Thu, 17 Jan 2008 12:08:59 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id 3g2F8CnzT8jUPaiT for ; Thu, 17 Jan 2008 12:08:59 -0800 (PST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m0HJAomd017668; Thu, 17 Jan 2008 14:10:50 -0500 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m0HJAnlA000516; Thu, 17 Jan 2008 14:10:49 -0500 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id m0HJAiM4019046; Thu, 17 Jan 2008 14:10:47 -0500 Message-ID: <478FA832.7030200@sandeen.net> Date: Thu, 17 Jan 2008 13:10:42 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Magpayo CC: David Chinner , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Repairing a possibly incomplete xfs_growfs command? Subject: Re: Repairing a possibly incomplete xfs_growfs command? References: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> <20080117030111.GH155259@sgi.com> <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> In-Reply-To: <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1200600542 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39725 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14163 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Magpayo wrote: > Someone else asked for the size of the block devices... here's the > output from /proc/partitions: > > 152 0 9523468862 etherd/e1.0 > 152 16 9523468862 etherd/e0.0 are those two assembled into your actual block device? They look each about 8T. Is the lvm device also in /proc/partitions? -Eric From owner-xfs@oss.sgi.com Thu Jan 17 12:10:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 12:10:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0HKAFst031000 for ; Thu, 17 Jan 2008 12:10:18 -0800 X-ASG-Debug-ID: 1200600632-7ae303360000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.purevideo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2C2E4C777BA for ; Thu, 17 Jan 2008 12:10:32 -0800 (PST) Received: from mail.purevideo.com (mail.purevideo.com [208.50.29.149]) by cuda.sgi.com with ESMTP id O4ha35fHTRDoxFZX for ; Thu, 17 Jan 2008 12:10:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: RE: Repairing a possibly incomplete xfs_growfs command? Subject: RE: Repairing a possibly incomplete xfs_growfs command? Date: Thu, 17 Jan 2008 12:04:47 -0800 Message-ID: <9CE70E6ED2C2F64FB5537A2973FA4F02535954@pvn-3001.purevideo.local> In-Reply-To: <478FA832.7030200@sandeen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Repairing a possibly incomplete xfs_growfs command? Thread-Index: AchZQC5sODYdpjb1St20lBiaF27SXQABPn4Q References: <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> <478FA832.7030200@sandeen.net> From: "Mark Magpayo" To: "Eric Sandeen" Cc: "David Chinner" , X-Barracuda-Connect: mail.purevideo.com[208.50.29.149] X-Barracuda-Start-Time: 1200600634 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39726 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m0HKAIst031014 X-archive-position: 14164 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmagpayo@purevideo.com Precedence: bulk X-list: xfs > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@sandeen.net] > Sent: Thursday, January 17, 2008 11:11 AM > To: Mark Magpayo > Cc: David Chinner; xfs@oss.sgi.com > Subject: Re: Repairing a possibly incomplete xfs_growfs command? > > Mark Magpayo wrote: > > > Someone else asked for the size of the block devices... here's the > > output from /proc/partitions: > > > > 152 0 9523468862 etherd/e1.0 > > 152 16 9523468862 etherd/e0.0 > > > are those two assembled into your actual block device? They look each > about 8T. > > Is the lvm device also in /proc/partitions? > > -Eric Here's the entire output: major minor #blocks name 3 0 512000 hda 3 1 511528 hda1 152 0 9523468862 etherd/e1.0 152 16 9523468862 etherd/e0.0 254 0 19046932480 dm-0 I believe dm-0 is the lvm device. Thanks, Mark From owner-xfs@oss.sgi.com Thu Jan 17 14:19:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 14:19:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0HMJlQs020061 for ; Thu, 17 Jan 2008 14:19:48 -0800 X-ASG-Debug-ID: 1200608402-16fa014a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E6AD85306CA for ; Thu, 17 Jan 2008 14:20:02 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id v9BVXo89fWwVol9k for ; Thu, 17 Jan 2008 14:20:02 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id AB84A18D92240; Thu, 17 Jan 2008 16:19:59 -0600 (CST) Message-ID: <478FD48F.1060707@sandeen.net> Date: Thu, 17 Jan 2008 16:19:59 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mark Magpayo CC: David Chinner , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Repairing a possibly incomplete xfs_growfs command? Subject: Re: Repairing a possibly incomplete xfs_growfs command? References: <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> <478FA832.7030200@sandeen.net> <9CE70E6ED2C2F64FB5537A2973FA4F02535954@pvn-3001.purevideo.local> In-Reply-To: <9CE70E6ED2C2F64FB5537A2973FA4F02535954@pvn-3001.purevideo.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1200608405 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39733 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14165 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Magpayo wrote: > Here's the entire output: > > major minor #blocks name > > 3 0 512000 hda > 3 1 511528 hda1 > 152 0 9523468862 etherd/e1.0 > 152 16 9523468862 etherd/e0.0 > 254 0 19046932480 dm-0 > > > I believe dm-0 is the lvm device. Yep, in 1k units, so: 19046932480*1024 19504058859520 and: superblock read failed, offset 19504058859520, size 2048, ag 64, rval 0 so it's trying to read a 2k (?) superblock right in the last 1k of the device? Hrm. (Dave, Barry - isn't that 2048 the sector size, not block size?) Also from your sb 0 printout: blocksize = 4096 dblocks = 11904332800 is 48760147148800, exactly 2.5x bigger than your device is. Weird. -Eric From owner-xfs@oss.sgi.com Thu Jan 17 14:44:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 14:44:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0HMiJOS022764 for ; Thu, 17 Jan 2008 14:44:25 -0800 X-ASG-Debug-ID: 1200609877-24fc006d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 41B88530A41 for ; Thu, 17 Jan 2008 14:44:37 -0800 (PST) Received: from postoffice.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id KFzvBJk4gLaWQV4K for ; Thu, 17 Jan 2008 14:44:37 -0800 (PST) Received: from edge.scott.net.au (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 03EED92D0BE; Fri, 18 Jan 2008 09:44:36 +1100 (EST) X-ASG-Orig-Subj: Re: Repairing a possibly incomplete xfs_growfs command? Subject: Re: Repairing a possibly incomplete xfs_growfs command? From: Nathan Scott Reply-To: nscott@aconex.com To: Eric Sandeen Cc: Mark Magpayo , David Chinner , xfs@oss.sgi.com In-Reply-To: <478FD48F.1060707@sandeen.net> References: <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> <478FA832.7030200@sandeen.net> <9CE70E6ED2C2F64FB5537A2973FA4F02535954@pvn-3001.purevideo.local> <478FD48F.1060707@sandeen.net> Content-Type: text/plain Organization: Aconex Date: Fri, 18 Jan 2008 09:47:34 +1100 Message-Id: <1200610054.9463.218.camel@edge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1200609878 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39733 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14166 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Thu, 2008-01-17 at 16:19 -0600, Eric Sandeen wrote: > > Yep, in 1k units, so: > > 19046932480*1024 > 19504058859520 > > and: > > superblock read failed, offset 19504058859520, size 2048, ag 64, rval > 0 > > so it's trying to read a 2k (?) superblock right in the last 1k of the > device? Hrm. (Dave, Barry - isn't that 2048 the sector size, not > block > size?) > > Also from your sb 0 printout: > > blocksize = 4096 > dblocks = 11904332800 sectsize = 512 sectlog = 9 So, SB reckons its a regular 512 byte sector size. Perhaps the device driver is reporting a 2K sector size from the BLKSSZGET ioctl? That'd be wierd, cos mkfs would have issued a warning when creating with 512 byte sectors. *shrug*. > is 48760147148800, exactly 2.5x bigger than your device is. Weird. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jan 17 15:15:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 15:15:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0HNF7wZ027393 for ; Thu, 17 Jan 2008 15:15:11 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00228; Fri, 18 Jan 2008 10:15:21 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0HNFJLF28714061; Fri, 18 Jan 2008 10:15:20 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0HNFHPA28844149; Fri, 18 Jan 2008 10:15:17 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 18 Jan 2008 10:15:17 +1100 From: David Chinner To: Mark Magpayo Cc: xfs@oss.sgi.com Subject: Re: Repairing a possibly incomplete xfs_growfs command? Message-ID: <20080117231517.GF155407@sgi.com> References: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> <20080117030111.GH155259@sgi.com> <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14167 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Jan 17, 2008 at 09:29:22AM -0800, Mark Magpayo wrote: > > On Wed, Jan 16, 2008 at 03:19:19PM -0800, Mark Magpayo wrote: > > > Hi, > > > > > > So I have run across a strange situation which I hope there > > > are some gurus out there to help. > > > > > > The original setup was a logical volume of 8.9TB. I extended > > > the volume to 17.7TB and attempted to run xfs_growfs. I am > > > not sure whether the command actually finished, as after I ran > > > the command, the metadata was displayed, but there was no > > > nothing that stated the the number of data blocks had changed. > > > I was just returned to the prompt, so I'm not sure whether the > > > command completed or not.. > > > > Hmmm - what kernel and what version of xfsprogs are you using? > > (xfs_growfs -V). > > xfs_growfs version 2.9.4 Ok, that's recent - what kernel? (uname -a) > > Also, can you post the output of the growfs command if you still > > have it? > > > > If not, the output of: > > > > # xfs_db -r -c 'sb 0' -c p > > #xfs_db -r -c 'sb 0' -c p /dev/vg0/lv0 > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 11904332800 = 44TB? .... > agblocks = 74402080 = ~283GB > agcount = 160 160*283GB = 44TB. Hold on - 160 AGs? I saw this exact same growfs failure signature just before Christmas at a customer site on an old kernel and xfsprogs. I really need to know what kernel you are running to determine if we may have fixed this bug or not.... But, I did manage to recover that filesystem successfully, so I can give you a simple recipe to fix it up and it won't take me 4 hours on IRC to understand the scope of the damage completely. BTW, if you wanted 18TB, that should be ~64AGs at that size AG so my initial suspicion was confirmed.... > rbmblocks = 0 > logblocks = 32768 > versionnum = 0x3094 .... > icount = 1335040 > ifree = 55 > fdblocks = 9525955616 = 35TB So the free block count got updated as well. Ok, that means once we've fixed up the number of AGs and block count, we'll need to run xfs_repair to ensure all the accounting is correct.... So the superblock in AG1 shoul dhave the original (pre-grow) geometry in it: > #xfs_db -r -c 'sb 1' -c p /dev/vg0/lv0 > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 2380866560 = 8.9TB .... > agblocks = 74402080 > agcount = 32 Yup, 32 AGs originally. > rbmblocks = 0 > logblocks = 32768 > versionnum = 0x3094 .... > icount = 1334912 > ifree = 59 > fdblocks = 2809815 Yeah, you didn't have much free space, did you? ;) FWIW: sb.0.fdblocks - (sb.0.dblocks - sb.1.dblocks) = 9525955616 - (11904332800 - 2380866560) = 2489376 Which means we can use simple subtraction to fix up the free block count. You'll need to run xfs_reapir to fix this after we've fixed the geometry. The way to fix this is to manually fix up the agcount and dblocks in all the AGs. Seeing as you simply doubled the volume size, that is relatively easy to do. dblocks should be 2*2380866560 = 4761733120 blocks = 19,046,932,480 bytes. Your device is 19,504,058,859,520 bytes in size, so this should fit just fine. # for i in `seq 0 1 63`; do > xfs_db -x -c "sb $i" -c 'write agcount 64' -c 'write dblock 4761733120' /dev/vg0/lv0 > done Then run 'xfs_repair -n /dev/vg0/lv0' to check that phase 1 will pass (i.e. it can read the last block of the filesystem). If phase 1 completes, then you can kill it and run xfs_repair again without the '-n' flag. Once that completes, you should have a mountable filesystem that is ~18TB in size. If you want, once you've mounted it run xfs_growfs again to extend the filesystem completely to the end of new device.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jan 17 15:34:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 15:34:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0HNYCA3029493 for ; Thu, 17 Jan 2008 15:34:15 -0800 X-ASG-Debug-ID: 1200612871-6309022e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.purevideo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 95051C7A269 for ; Thu, 17 Jan 2008 15:34:31 -0800 (PST) Received: from mail.purevideo.com (mail.purevideo.com [208.50.29.149]) by cuda.sgi.com with ESMTP id 5j1KrsGmhHmVLbYU for ; Thu, 17 Jan 2008 15:34:31 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: RE: Repairing a possibly incomplete xfs_growfs command? Subject: RE: Repairing a possibly incomplete xfs_growfs command? Date: Thu, 17 Jan 2008 15:29:17 -0800 Message-ID: <9CE70E6ED2C2F64FB5537A2973FA4F0253595A@pvn-3001.purevideo.local> In-Reply-To: <20080117231517.GF155407@sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Repairing a possibly incomplete xfs_growfs command? Thread-Index: AchZXh8u0XsFC3fDQVqZiBKwHAgLBQAAndYw References: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> <20080117030111.GH155259@sgi.com> <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> <20080117231517.GF155407@sgi.com> From: "Mark Magpayo" To: "David Chinner" Cc: X-Barracuda-Connect: mail.purevideo.com[208.50.29.149] X-Barracuda-Start-Time: 1200612871 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39738 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m0HNYFA3029499 X-archive-position: 14168 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmagpayo@purevideo.com Precedence: bulk X-list: xfs > -----Original Message----- > From: David Chinner [mailto:dgc@sgi.com] > Sent: Thursday, January 17, 2008 3:15 PM > To: Mark Magpayo > Cc: xfs@oss.sgi.com > Subject: Re: Repairing a possibly incomplete xfs_growfs command? > > On Thu, Jan 17, 2008 at 09:29:22AM -0800, Mark Magpayo wrote: > > > On Wed, Jan 16, 2008 at 03:19:19PM -0800, Mark Magpayo wrote: > > > > Hi, > > > > > > > > So I have run across a strange situation which I hope there > > > > are some gurus out there to help. > > > > > > > > The original setup was a logical volume of 8.9TB. I extended > > > > the volume to 17.7TB and attempted to run xfs_growfs. I am > > > > not sure whether the command actually finished, as after I ran > > > > the command, the metadata was displayed, but there was no > > > > nothing that stated the the number of data blocks had changed. > > > > I was just returned to the prompt, so I'm not sure whether the > > > > command completed or not.. > > > > > > Hmmm - what kernel and what version of xfsprogs are you using? > > > (xfs_growfs -V). > > > > xfs_growfs version 2.9.4 > > Ok, that's recent - what kernel? (uname -a) > > > > Also, can you post the output of the growfs command if you still > > > have it? > > > > > > If not, the output of: > > > > > > # xfs_db -r -c 'sb 0' -c p > > > > #xfs_db -r -c 'sb 0' -c p /dev/vg0/lv0 > > magicnum = 0x58465342 > > blocksize = 4096 > > dblocks = 11904332800 > > = 44TB? > .... > > agblocks = 74402080 > = ~283GB > > > agcount = 160 > > 160*283GB = 44TB. > > Hold on - 160 AGs? I saw this exact same growfs failure signature > just before Christmas at a customer site on an old kernel and > xfsprogs. I really need to know what kernel you are running to > determine if we may have fixed this bug or not.... > > But, I did manage to recover that filesystem successfully, > so I can give you a simple recipe to fix it up and it won't > take me 4 hours on IRC to understand the scope of the damage > completely. > > BTW, if you wanted 18TB, that should be ~64AGs at that size AG > so my initial suspicion was confirmed.... > > > rbmblocks = 0 > > logblocks = 32768 > > versionnum = 0x3094 > .... > > icount = 1335040 > > ifree = 55 > > fdblocks = 9525955616 > = 35TB > > So the free block count got updated as well. > > Ok, that means once we've fixed up the number of AGs and block > count, we'll need to run xfs_repair to ensure all the accounting > is correct.... > > > So the superblock in AG1 shoul dhave the original (pre-grow) > geometry in it: > > > #xfs_db -r -c 'sb 1' -c p /dev/vg0/lv0 > > magicnum = 0x58465342 > > blocksize = 4096 > > dblocks = 2380866560 > > = 8.9TB > .... > > agblocks = 74402080 > > agcount = 32 > > Yup, 32 AGs originally. > > > rbmblocks = 0 > > logblocks = 32768 > > versionnum = 0x3094 > .... > > icount = 1334912 > > ifree = 59 > > fdblocks = 2809815 > > Yeah, you didn't have much free space, did you? ;) > > FWIW: sb.0.fdblocks - (sb.0.dblocks - sb.1.dblocks) > = 9525955616 - (11904332800 - 2380866560) > = 2489376 > > Which means we can use simple subtraction to fix up the free > block count. You'll need to run xfs_reapir to fix this after > we've fixed the geometry. > > The way to fix this is to manually fix up the agcount > and dblocks in all the AGs. Seeing as you simply doubled the > volume size, that is relatively easy to do. dblocks should > be 2*2380866560 = 4761733120 blocks = 19,046,932,480 bytes. > > Your device is 19,504,058,859,520 bytes in size, so this should > fit just fine. > > # for i in `seq 0 1 63`; do > > xfs_db -x -c "sb $i" -c 'write agcount 64' -c 'write dblock 4761733120' > /dev/vg0/lv0 > > done > > Then run 'xfs_repair -n /dev/vg0/lv0' to check that phase 1 will > pass (i.e. it can read the last block of the filesystem). If phase > 1 completes, then you can kill it and run xfs_repair again without > the '-n' flag. > > Once that completes, you should have a mountable filesystem that is > ~18TB in size. > > If you want, once you've mounted it run xfs_growfs again to extend > the filesystem completely to the end of new device.... > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group This is quite a relief to know that this is a fairly straightforward fix! What luck that you had encountered it recently, I really appreciate the help. Here's my uname output: Linux purenas 2.6.16.55-c1 #1 SMP Fri Oct 19 16:45:15 EDT 2007 x86_64 GNU/Linux Maybe you guys fixed the bug already? iirc, I may have run xfs_growfs with an older version of xfsprogs, then was advised to update to the newest and try it again. I may have run it on a version that still contained the bug? So is this all I need then prior to an xfs_repair?: > # for i in `seq 0 1 63`; do > > xfs_db -x -c "sb $i" -c 'write agcount 64' -c 'write dblock 4761733120' > /dev/vg0/lv0 I really appreciate all of the help everyone has given. =) Thanks, Mark From owner-xfs@oss.sgi.com Thu Jan 17 15:45:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 15:46:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0HNjr8V002327 for ; Thu, 17 Jan 2008 15:45:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01325; Fri, 18 Jan 2008 10:46:07 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m0HNk5LF28847964; Fri, 18 Jan 2008 10:46:06 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m0HNk4x228856334; Fri, 18 Jan 2008 10:46:04 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 18 Jan 2008 10:46:04 +1100 From: David Chinner To: Mark Magpayo Cc: xfs@oss.sgi.com Subject: Re: Repairing a possibly incomplete xfs_growfs command? Message-ID: <20080117234604.GG155407@sgi.com> References: <9CE70E6ED2C2F64FB5537A2973FA4F0253594C@pvn-3001.purevideo.local> <20080117030111.GH155259@sgi.com> <9CE70E6ED2C2F64FB5537A2973FA4F02535951@pvn-3001.purevideo.local> <20080117231517.GF155407@sgi.com> <9CE70E6ED2C2F64FB5537A2973FA4F0253595A@pvn-3001.purevideo.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9CE70E6ED2C2F64FB5537A2973FA4F0253595A@pvn-3001.purevideo.local> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14169 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Jan 17, 2008 at 03:29:17PM -0800, Mark Magpayo wrote: > This is quite a relief to know that this is a fairly straightforward > fix! What luck that you had encountered it recently, I really > appreciate the help. Here's my uname output: > > Linux purenas 2.6.16.55-c1 #1 SMP Fri Oct 19 16:45:15 EDT 2007 x86_64 > GNU/Linux > > Maybe you guys fixed the bug already? /me breathes a sigh of relief I think we have: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=20f4ebf2bf2f57c1a9abb3655391336cc90314b3 [XFS] Make growfs work for amounts greater than 2TB > iirc, I may have run xfs_growfs with an older version of xfsprogs, then > was advised to update to the newest and try it again. I may have run it > on a version that still contained the bug? Kernel bug, not userspace bug, AFAICT. > So is this all I need then prior to an xfs_repair?: > > > # for i in `seq 0 1 63`; do > > > xfs_db -x -c "sb $i" -c 'write agcount 64' -c 'write dblock 4761733120' > > /dev/vg0/lv0 Yes, I think that is all that is necessary (that+repair was what fixed the problem at the customer site successfully). Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jan 17 16:11:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 16:12:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m0I0BntF019562 for ; Thu, 17 Jan 2008 16:11:51 -0800 X-ASG-Debug-ID: 1200615126-630802a10000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fergie.hostexchange.net.au (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A0AC5C7A309 for ; Thu, 17 Jan 2008 16:12:06 -0800 (PST) Received: from fergie.hostexchange.net.au (fergie.hostexchange.net.au [64.34.177.147]) by cuda.sgi.com with ESMTP id F9TvbXPnkbnYxaFp for ; Thu, 17 Jan 2008 16:12:06 -0800 (PST) Received: from localhost (localhost) by fergie.hostexchange.net.au (8.13.4/8.13.4/Debian-3sarge3) id m0I0C5tZ031515; Fri, 18 Jan 2008 11:12:05 +1100 Date: Fri, 18 Jan 2008 11:12:05 +1100 From: Mail Delivery Subsystem Message-Id: <200801180012.m0I0C5tZ031515@fergie.hostexchange.net.au> To: postmaster@fergie.hostexchange.net.au To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="m0I0C5tZ031515.1200615125/fergie.hostexchange.net.au" X-ASG-Orig-Subj: Returned mail: see transcript for details Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-Barracuda-Connect: fergie.hostexchange.net.au[64.34.177.147] X-Barracuda-Start-Time: 1200615128 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.39742 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14170 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@fergie.hostexchange.net.au Precedence: bulk X-list: xfs This is a MIME-encapsulated message --m0I0C5tZ031515.1200615125/fergie.hostexchange.net.au The original message was received at Fri, 18 Jan 2008 11:12:02 +1100 from [222.106.183.12] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 554 5.0.0 MX list for d9810.rotary.org.au. points back to fergie.hostexchange.net.au 554 5.3.5 Local configuration error --m0I0C5tZ031515.1200615125/fergie.hostexchange.net.au Content-Type: message/delivery-status Reporting-MTA: dns; fergie.hostexchange.net.au Received-From-MTA: DNS; [222.106.183.12] Arrival-Date: Fri, 18 Jan 2008 11:12:02 +1100 Final-Recipient: RFC822; warrandyte@d9810.rotary.org.au Action: failed Status: 5.5.0 Remote-MTA: DNS; d9810.rotary.org.au Last-Attempt-Date: Fri, 18 Jan 2008 11:12:04 +1100 --m0I0C5tZ031515.1200615125/fergie.hostexchange.net.au Content-Type: text/rfc822-headers Return-Path: Received: from d9810.rotary.org.au ([222.106.183.12]) by fergie.hostexchange.net.au (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m0I0C1tZ031500 for ; Fri, 18 Jan 2008 11:12:02 +1100 Message-Id: <200801180012.m0I0C1tZ031500@fergie.hostexchange.net.au> From: linux-xfs@oss.sgi.com To: warrandyte@d9810.rotary.org.au Subject: Date: Fri, 18 Jan 2008 09:12:23 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal --m0I0C5tZ031515.1200615125/fergie.hostexchange.net.au-- From owner-xfs@oss.sgi.com Thu Jan 17 20:42:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 20:42:32 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0I4gHte021080 for ; Thu, 17 Jan 2008 20:42:24 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08036; Fri, 18 Jan 2008 15:42:34 +1100 Date: Fri, 18 Jan 2008 15:43:47 +1100 To: "xfs@oss.sgi.com" Subject: [REVIEW 0/2] Case insensitive support for XFS From: "Barry Naujok" Organization: SGI Cc: xfs-dev Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14171 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs In the following two emails is contains patches for case-insensitive and Unicode support for XFS in Linux. It implements case-insensitivity utilising a Unicode case folding table stored on disk generated from http://www.unicode.org/Public/UNIDATA/CaseFolding.txt As the filesystem stores names as Unicode (UTF-8), the "nls" mount option has been added to support systems not utilising UTF-8 natively. If the nls mount option is not used, it will use the default NLS defined in the kernel's config. To allow case-insensitivity to be a mount option rather than a mkfs option, the hashes stored on disk are always case-folded. This is indicated by the new "unicode" bit in the superblock. This bit also associated with the presence of the case-folding table on disk. This affects both directory and extended attribute names. With the case-folding table on disk, it allows us to upgrade the table in the future while retaining backwards and forwards compatibility. It also allows special case tables such as Turkic case which is supported in this patch set. There are two mount options for enabling case-insensitivity on a Unicode XFS filesystem: - "ci" - enables case-insensitivity for file names - "ciattr" - enables case-insensitivity for extended attributes. xfs_repair and xfs_db are fully aware of the case-folding table. xfs_db has a basic "cft" command which can show the table's header. From owner-xfs@oss.sgi.com Thu Jan 17 20:42:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 17 Jan 2008 20:42:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, J_CHICKENPOX_41,J_CHICKENPOX_42,J_CHICKENPOX_45,J_CHICKENPOX_47, J_CHICKENPOX_48,J_CHICKENPOX_51,J_CHICKENPOX_53,J_CHICKENPOX_55, J_CHICKENPOX_57,J_CHICKENPOX_61,J_CHICKENPOX_62,J_CHICKENPOX_65, J_CHICKENPOX_66,J_CHICKENPOX_71 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m0I4gJHN021083 for ; Thu, 17 Jan 2008 20:42:24 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08039; Fri, 18 Jan 2008 15:42:36 +1100 Date: Fri, 18 Jan 2008 15:43:50 +1100 To: "xfs@oss.sgi.com" Subject: [REVIEW 1/2] Case insensitive support for XFS - kernel patch From: "Barry Naujok" Organization: SGI Cc: xfs-dev Content-Type: multipart/mixed; boundary=----------86aCZzNf3aen1MAxxPn749 MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 10:09:26 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14172 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs ------------86aCZzNf3aen1MAxxPn749 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 7bit This patch should apply to 2.6.24-rc6. Makefile | 1 linux-2.6/xfs_expor