From jblunck@suse.de Mon Nov 2 04:06:59 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2A6x09032757 for ; Mon, 2 Nov 2009 04:06:59 -0600 X-ASG-Debug-ID: 1257156431-5cdd02fe0000-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 974BA1B38376; Mon, 2 Nov 2009 02:07:11 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by cuda.sgi.com with ESMTP id BAFmdhoqSU390FV1; Mon, 02 Nov 2009 02:07:11 -0800 (PST) Received: from relay1.suse.de (relay-ext.suse.de [195.135.221.8]) by mx2.suse.de (Postfix) with ESMTP id 954FB8A95F; Mon, 2 Nov 2009 11:07:10 +0100 (CET) From: Jan Blunck To: linux-fsdevel@vger.kernel.org Cc: Matthew Wilcox , linux-kernel@vger.kernel.org, Jan Blunck , Alex Elder , xfs-masters@oss.sgi.com, Christoph Hellwig , Dave Chinner , Eric Sandeen , Niv Sardi , Felix Blyakher , xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 27/27] BKL: Remove BKL from xfs Subject: [PATCH 27/27] BKL: Remove BKL from xfs Date: Mon, 2 Nov 2009 11:05:07 +0100 Message-Id: <1257156307-24175-28-git-send-email-jblunck@suse.de> X-Mailer: git-send-email 1.6.4.2 In-Reply-To: <1257156307-24175-1-git-send-email-jblunck@suse.de> References: <1257156307-24175-1-git-send-email-jblunck@suse.de> X-Barracuda-Connect: cantor2.suse.de[195.135.220.15] X-Barracuda-Start-Time: 1257156432 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13515 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean BKL is only used in fill_super. It is safe to remove it. Signed-off-by: Jan Blunck --- fs/xfs/linux-2.6/xfs_super.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c index 7426166..18a4b8e 100644 --- a/fs/xfs/linux-2.6/xfs_super.c +++ b/fs/xfs/linux-2.6/xfs_super.c @@ -1412,8 +1412,6 @@ xfs_fs_fill_super( int flags = 0, error = ENOMEM; char *mtpt = NULL; - lock_kernel(); - mp = kzalloc(sizeof(struct xfs_mount), GFP_KERNEL); if (!mp) goto out; @@ -1508,7 +1506,6 @@ xfs_fs_fill_super( kfree(mtpt); xfs_itrace_exit(XFS_I(sb->s_root->d_inode)); - unlock_kernel(); return 0; out_filestream_unmount: @@ -1525,7 +1522,6 @@ xfs_fs_fill_super( kfree(mtpt); kfree(mp); out: - unlock_kernel(); return -error; fail_vnrele: -- 1.6.4.2 From jblunck@suse.de Mon Nov 2 04:06:53 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_43,J_CHICKENPOX_45,J_CHICKENPOX_64,J_CHICKENPOX_66, LOCAL_GNU_PATCH autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2A6q6t032742 for ; Mon, 2 Nov 2009 04:06:52 -0600 X-ASG-Debug-ID: 1257156424-620901de0000-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 1E2B153621; Mon, 2 Nov 2009 02:07:04 -0800 (PST) Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by cuda.sgi.com with ESMTP id BC97xJygbh21F3Ms; Mon, 02 Nov 2009 02:07:04 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 0CC5D8E8CC; Mon, 2 Nov 2009 11:07:01 +0100 (CET) From: Jan Blunck To: linux-fsdevel@vger.kernel.org Cc: Matthew Wilcox , linux-kernel@vger.kernel.org, Jan Blunck , Eric Van Hensbergen , Ron Minnich , Latchesar Ionkov , Abhishek Kulkarni , Al Viro , James Morris , Andrew Morton , Alexey Dobriyan , Christoph Hellwig , Roman Zippel , David Howells , Ian Kent , Jeff Moyer , "Sergey S. Kostyliov" , Greg Kroah-Hartman , "Tigran A. Aivazian" , Eric Sesterhenn , Qinghuang Feng , Chris Mason , Yan Zheng , Sage Weil , Steve French , Jeff Layton , Jan Harkes , co@suse.de, da@cs.cmu.edu, Joel Becker , Coly Li , David VomLehn , Sukadev Bhattiprolu , Alan Cox , Serge Hallyn , Tyler Hicks , Dustin Kirkland , Boaz Harrosh , Benny Halevy , Jan Kara , Andreas Dilger , "Theodore Ts'o" , OGAWA Hirofumi , Denis Karpov , Miklos Szeredi , Csaba Henk , Tejun Heo , Jens Axboe , Steven Whitehouse , Jeff Dike , KOSAKI Motohiro , Nick Piggin , Wolfgang Illmeyer , Mikulas Patocka , Alessio Igor Bogani , Roel Kluin , William Irwin , Mel Gorman , David Woodhouse , Dave Kleikamp , Masayuki Hamaguchi , Trond Myklebust , Petr Vandrovec , Thomas Gleixner , Chuck Lever , "J. Bruce Fields" , Neil Brown , KONISHI Ryusuke , Jiro SEKIBA , Anton Altaparmakov , Mark Fasheh , Sunil Mushran , Bob Copeland , Anders Larsen , Wu Fengguang , Matt Mackall , Jeff Mahoney , Bernd Schmidt , Julia Lawall , Phillip Lougher , "Eric W. Biederman" , Arte m Bityutskiy , Adrian Hunter , Marcin Slusarz , Pekka Enberg , Clemens Ladisch , Evgeniy Dushistov , Alex Elder , xfs-masters@oss.sgi.com, Dave Chinner , Eric Sandeen , Niv Sardi , Felix Blyakher , v9fs-developer@lists.sourceforge.net, linux-afs@lists.infradead.org, autofs@linux.kernel.org, linux-btrfs@vger.kernel.org, linux-cifs-client@lists.samba.org, samba-technical@lists.samba.org, codalist@TELEMANN.coda.cs.cmu.edu, ecryptfs-devel@lists.launchpad.net, osd-dev@open-osd.org, linux-ext4@vger.kernel.org, fuse-devel@lists.sourceforge.net, cluster-devel@redhat.com, user-mode-linux-devel@lists.sourceforge.net, user-mode-linux-user@lists.sourceforge.net, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, linux-nfs@vger.kernel.org, users@nilfs.org, linux-ntfs-dev@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, linux-karma-devel@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 01/27] BKL: Push down BKL from do_new_mount() to the filesystems get_sb/fill_super operation Subject: [PATCH 01/27] BKL: Push down BKL from do_new_mount() to the filesystems get_sb/fill_super operation Date: Mon, 2 Nov 2009 11:04:41 +0100 Message-Id: <1257156307-24175-2-git-send-email-jblunck@suse.de> X-Mailer: git-send-email 1.6.4.2 In-Reply-To: <1257156307-24175-1-git-send-email-jblunck@suse.de> References: <1257156307-24175-1-git-send-email-jblunck@suse.de> X-Barracuda-Connect: cantor.suse.de[195.135.220.2] X-Barracuda-Start-Time: 1257156426 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I've read through all the code formerly covered by the BKL inside do_kern_mount() and have satisfied myself that it doesn't need the BKL any more. do_kern_mount() is already called without the BKL when mounting the rootfs and in nfsctl. do_kern_mount() calls vfs_kern_mount(), which is called from various places without BKL: simple_pin_fs(), nfs_do_clone_mount() through nfs_follow_mountpoint(), afs_mntpt_do_automount() through afs_mntpt_follow_link(). Both later functions are actually the filesystems follow_link inode operation. vfs_kern_mount() is calling the specified get_sb function and lets the filesystem do its job by calling the given fill_super function. Therefore I think it is safe to push down the BKL from the VFS to the low-level filesystems get_sb/fill_super operation. Signed-off-by: Jan Blunck Cc: Matthew Wilcox --- fs/9p/vfs_super.c | 9 ++++++++- fs/adfs/super.c | 8 +++++++- fs/affs/super.c | 9 ++++++++- fs/afs/super.c | 5 +++++ fs/autofs4/inode.c | 4 ++++ fs/befs/linuxvfs.c | 4 ++++ fs/bfs/inode.c | 9 ++++++++- fs/binfmt_misc.c | 6 +++++- fs/btrfs/super.c | 8 +++++++- fs/cifs/cifsfs.c | 12 ++++++++++-- fs/coda/inode.c | 8 +++++++- fs/configfs/mount.c | 5 +++++ fs/cramfs/inode.c | 8 +++++++- fs/devpts/inode.c | 13 +++++++++++-- fs/ecryptfs/main.c | 3 +++ fs/efs/super.c | 10 ++++++++-- fs/exofs/super.c | 7 ++++++- fs/ext2/super.c | 10 ++++++++-- fs/ext3/super.c | 9 ++++++++- fs/ext4/super.c | 9 ++++++--- fs/fat/namei_msdos.c | 6 +++++- fs/fat/namei_vfat.c | 6 +++++- fs/freevxfs/vxfs_super.c | 7 ++++++- fs/fuse/control.c | 9 ++++++++- fs/fuse/inode.c | 5 +++++ fs/gfs2/ops_fstype.c | 9 +++++++++ fs/hfs/super.c | 8 +++++++- fs/hfsplus/super.c | 8 +++++++- fs/hostfs/hostfs_kern.c | 4 ++++ fs/hpfs/super.c | 8 +++++++- fs/hppfs/hppfs.c | 4 ++++ fs/hugetlbfs/inode.c | 12 ++++++++++-- fs/isofs/inode.c | 8 +++++++- fs/jffs2/super.c | 11 +++++++++-- fs/jfs/super.c | 14 ++++++++++++-- fs/libfs.c | 10 +++++++++- fs/minix/inode.c | 8 +++++++- fs/namespace.c | 2 -- fs/ncpfs/inode.c | 8 +++++++- fs/nfs/super.c | 19 +++++++++++++++++++ fs/nfsd/nfsctl.c | 7 ++++++- fs/nilfs2/super.c | 9 ++++++++- fs/ntfs/super.c | 5 +++++ fs/ocfs2/dlm/dlmfs.c | 8 +++++++- fs/ocfs2/super.c | 5 +++++ fs/omfs/inode.c | 7 ++++++- fs/openpromfs/inode.c | 4 ++++ fs/proc/root.c | 9 ++++++++- fs/qnx4/inode.c | 8 +++++++- fs/ramfs/inode.c | 5 +++++ fs/reiserfs/super.c | 4 ++++ fs/romfs/super.c | 9 ++++++++- fs/smbfs/inode.c | 5 +++++ fs/squashfs/super.c | 6 ++++++ fs/sysfs/mount.c | 6 ++++++ fs/sysv/super.c | 24 +++++++++++++++++++----- fs/ubifs/super.c | 5 +++++ fs/udf/super.c | 8 +++++++- fs/ufs/super.c | 5 +++++ fs/xfs/linux-2.6/xfs_super.c | 4 ++++ 60 files changed, 412 insertions(+), 53 deletions(-) diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c index 14a8644..4156a0c 100644 --- a/fs/9p/vfs_super.c +++ b/fs/9p/vfs_super.c @@ -106,11 +106,15 @@ static int v9fs_get_sb(struct file_system_type *fs_type, int flags, struct p9_fid *fid; int retval = 0; + lock_kernel(); + P9_DPRINTK(P9_DEBUG_VFS, " \n"); v9ses = kzalloc(sizeof(struct v9fs_session_info), GFP_KERNEL); - if (!v9ses) + if (!v9ses) { + unlock_kernel(); return -ENOMEM; + } fid = v9fs_session_init(v9ses, dev_name, data); if (IS_ERR(fid)) { @@ -155,6 +159,7 @@ static int v9fs_get_sb(struct file_system_type *fs_type, int flags, P9_DPRINTK(P9_DEBUG_VFS, " simple set mount, return 0\n"); simple_set_mnt(mnt, sb); + unlock_kernel(); return 0; free_stat: @@ -167,12 +172,14 @@ clunk_fid: close_session: v9fs_session_close(v9ses); kfree(v9ses); + unlock_kernel(); return retval; release_sb: p9stat_free(st); kfree(st); deactivate_locked_super(sb); + unlock_kernel(); return retval; } diff --git a/fs/adfs/super.c b/fs/adfs/super.c index 6910a98..e94f111 100644 --- a/fs/adfs/super.c +++ b/fs/adfs/super.c @@ -351,11 +351,15 @@ static int adfs_fill_super(struct super_block *sb, void *data, int silent) struct adfs_sb_info *asb; struct inode *root; + lock_kernel(); + sb->s_flags |= MS_NODIRATIME; asb = kzalloc(sizeof(*asb), GFP_KERNEL); - if (!asb) + if (!asb) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = asb; /* set default options */ @@ -473,6 +477,7 @@ static int adfs_fill_super(struct super_block *sb, void *data, int silent) goto error; } else sb->s_root->d_op = &adfs_dentry_operations; + unlock_kernel(); return 0; error_free_bh: @@ -480,6 +485,7 @@ error_free_bh: error: sb->s_fs_info = NULL; kfree(asb); + unlock_kernel(); return -EINVAL; } diff --git a/fs/affs/super.c b/fs/affs/super.c index 104fdcb..135f0d3 100644 --- a/fs/affs/super.c +++ b/fs/affs/super.c @@ -298,6 +298,8 @@ static int affs_fill_super(struct super_block *sb, void *data, int silent) u8 sig[4]; int ret = -EINVAL; + lock_kernel(); + save_mount_options(sb, data); pr_debug("AFFS: read_super(%s)\n",data ? (const char *)data : "no options"); @@ -307,8 +309,10 @@ static int affs_fill_super(struct super_block *sb, void *data, int silent) sb->s_flags |= MS_NODIRATIME; sbi = kzalloc(sizeof(struct affs_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbi; mutex_init(&sbi->s_bmlock); @@ -316,6 +320,7 @@ static int affs_fill_super(struct super_block *sb, void *data, int silent) &blocksize,&sbi->s_prefix, sbi->s_volume, &mount_flags)) { printk(KERN_ERR "AFFS: Error parsing options\n"); + unlock_kernel(); return -EINVAL; } /* N.B. after this point s_prefix must be released */ @@ -486,6 +491,7 @@ got_root: sb->s_root->d_op = &affs_dentry_operations; pr_debug("AFFS: s_flags=%lX\n",sb->s_flags); + unlock_kernel(); return 0; /* @@ -500,6 +506,7 @@ out_error_noinode: kfree(sbi->s_prefix); kfree(sbi); sb->s_fs_info = NULL; + unlock_kernel(); return ret; } diff --git a/fs/afs/super.c b/fs/afs/super.c index e1ea1c2..108fb3e 100644 --- a/fs/afs/super.c +++ b/fs/afs/super.c @@ -294,12 +294,15 @@ static int afs_fill_super(struct super_block *sb, void *data) struct inode *inode = NULL; int ret; + lock_kernel(); + _enter(""); /* allocate a superblock info record */ as = kzalloc(sizeof(struct afs_super_info), GFP_KERNEL); if (!as) { _leave(" = -ENOMEM"); + unlock_kernel(); return -ENOMEM; } @@ -329,6 +332,7 @@ static int afs_fill_super(struct super_block *sb, void *data) sb->s_root = root; _leave(" = 0"); + unlock_kernel(); return 0; error_inode: @@ -342,6 +346,7 @@ error: sb->s_fs_info = NULL; _leave(" = %d", ret); + unlock_kernel(); return ret; } diff --git a/fs/autofs4/inode.c b/fs/autofs4/inode.c index 69c8142..3adaba9 100644 --- a/fs/autofs4/inode.c +++ b/fs/autofs4/inode.c @@ -323,6 +323,8 @@ int autofs4_fill_super(struct super_block *s, void *data, int silent) struct autofs_sb_info *sbi; struct autofs_info *ino; + lock_kernel(); + sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); if (!sbi) goto fail_unlock; @@ -418,6 +420,7 @@ int autofs4_fill_super(struct super_block *s, void *data, int silent) * Success! Install the root dentry now to indicate completion. */ s->s_root = root; + unlock_kernel(); return 0; /* @@ -439,6 +442,7 @@ fail_free: kfree(sbi); s->s_fs_info = NULL; fail_unlock: + unlock_kernel(); return -EINVAL; } diff --git a/fs/befs/linuxvfs.c b/fs/befs/linuxvfs.c index 33baf27..f2aa193 100644 --- a/fs/befs/linuxvfs.c +++ b/fs/befs/linuxvfs.c @@ -759,6 +759,8 @@ befs_fill_super(struct super_block *sb, void *data, int silent) const unsigned long sb_block = 0; const off_t x86_sb_off = 512; + lock_kernel(); + save_mount_options(sb, data); sb->s_fs_info = kmalloc(sizeof (*befs_sb), GFP_KERNEL); @@ -867,6 +869,7 @@ befs_fill_super(struct super_block *sb, void *data, int silent) befs_sb->nls = load_nls_default(); } + unlock_kernel(); return 0; /*****************/ unacquire_bh: @@ -877,6 +880,7 @@ befs_fill_super(struct super_block *sb, void *data, int silent) unacquire_none: sb->s_fs_info = NULL; + unlock_kernel(); return ret; } diff --git a/fs/bfs/inode.c b/fs/bfs/inode.c index 6f60336..4bff506 100644 --- a/fs/bfs/inode.c +++ b/fs/bfs/inode.c @@ -356,9 +356,13 @@ static int bfs_fill_super(struct super_block *s, void *data, int silent) long ret = -EINVAL; unsigned long i_sblock, i_eblock, i_eoff, s_size; + lock_kernel(); + info = kzalloc(sizeof(*info), GFP_KERNEL); - if (!info) + if (!info) { + unlock_kernel(); return -ENOMEM; + } s->s_fs_info = info; sb_set_blocksize(s, BFS_BSIZE); @@ -463,6 +467,7 @@ static int bfs_fill_super(struct super_block *s, void *data, int silent) kfree(info->si_imap); kfree(info); s->s_fs_info = NULL; + unlock_kernel(); return -EIO; } @@ -484,12 +489,14 @@ static int bfs_fill_super(struct super_block *s, void *data, int silent) } dump_imap("read_super", s); mutex_init(&info->bfs_lock); + unlock_kernel(); return 0; out: brelse(bh); kfree(info); s->s_fs_info = NULL; + unlock_kernel(); return ret; } diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c index c4e8353..ca0e22d 100644 --- a/fs/binfmt_misc.c +++ b/fs/binfmt_misc.c @@ -695,9 +695,13 @@ static int bm_fill_super(struct super_block * sb, void * data, int silent) [3] = {"register", &bm_register_operations, S_IWUSR}, /* last one */ {""} }; - int err = simple_fill_super(sb, 0x42494e4d, bm_files); + int err; + + lock_kernel(); + err = simple_fill_super(sb, 0x42494e4d, bm_files); if (!err) sb->s_op = &s_ops; + unlock_kernel(); return err; } diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 752a546..e5cd2cf 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -480,13 +480,17 @@ static int btrfs_get_sb(struct file_system_type *fs_type, int flags, fmode_t mode = FMODE_READ; int error = 0; + lock_kernel(); + if (!(flags & MS_RDONLY)) mode |= FMODE_WRITE; error = btrfs_parse_early_options(data, mode, fs_type, &subvol_name, &fs_devices); - if (error) + if (error) { + unlock_kernel(); return error; + } error = btrfs_scan_one_device(dev_name, mode, fs_type, &fs_devices); if (error) @@ -555,6 +559,7 @@ static int btrfs_get_sb(struct file_system_type *fs_type, int flags, mnt->mnt_root = root; kfree(subvol_name); + unlock_kernel(); return 0; error_s: @@ -563,6 +568,7 @@ error_close_devices: btrfs_close_devices(fs_devices); error_free_subvol_name: kfree(subvol_name); + unlock_kernel(); return error; } diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index 9a5e4f5..09ccb9d 100644 --- a/fs/cifs/cifsfs.c +++ b/fs/cifs/cifsfs.c @@ -596,22 +596,30 @@ cifs_get_sb(struct file_system_type *fs_type, int flags, const char *dev_name, void *data, struct vfsmount *mnt) { int rc; - struct super_block *sb = sget(fs_type, NULL, set_anon_super, NULL); + struct super_block *sb; + + lock_kernel(); + + sb = sget(fs_type, NULL, set_anon_super, NULL); cFYI(1, ("Devname: %s flags: %d ", dev_name, flags)); - if (IS_ERR(sb)) + if (IS_ERR(sb)) { + unlock_kernel(); return PTR_ERR(sb); + } sb->s_flags = flags; rc = cifs_read_super(sb, data, dev_name, flags & MS_SILENT ? 1 : 0); if (rc) { deactivate_locked_super(sb); + unlock_kernel(); return rc; } sb->s_flags |= MS_ACTIVE; simple_set_mnt(mnt, sb); + unlock_kernel(); return 0; } diff --git a/fs/coda/inode.c b/fs/coda/inode.c index 830f51a..d081fc5 100644 --- a/fs/coda/inode.c +++ b/fs/coda/inode.c @@ -147,6 +147,8 @@ static int coda_fill_super(struct super_block *sb, void *data, int silent) int error; int idx; + lock_kernel(); + idx = get_device_index((struct coda_mount_data *) data); /* Ignore errors in data, for backward compatibility */ @@ -158,11 +160,13 @@ static int coda_fill_super(struct super_block *sb, void *data, int silent) vc = &coda_comms[idx]; if (!vc->vc_inuse) { printk("coda_read_super: No pseudo device\n"); + unlock_kernel(); return -EINVAL; } if ( vc->vc_sb ) { printk("coda_read_super: Device already mounted\n"); + unlock_kernel(); return -EBUSY; } @@ -196,7 +200,8 @@ static int coda_fill_super(struct super_block *sb, void *data, int silent) sb->s_root = d_alloc_root(root); if (!sb->s_root) goto error; - return 0; + unlock_kernel(); + return 0; error: if (root) @@ -204,6 +209,7 @@ static int coda_fill_super(struct super_block *sb, void *data, int silent) if (vc) vc->vc_sb = NULL; + unlock_kernel(); return -EINVAL; } diff --git a/fs/configfs/mount.c b/fs/configfs/mount.c index 8421cea..5b2e06e 100644 --- a/fs/configfs/mount.c +++ b/fs/configfs/mount.c @@ -71,6 +71,8 @@ static int configfs_fill_super(struct super_block *sb, void *data, int silent) struct inode *inode; struct dentry *root; + lock_kernel(); + sb->s_blocksize = PAGE_CACHE_SIZE; sb->s_blocksize_bits = PAGE_CACHE_SHIFT; sb->s_magic = CONFIGFS_MAGIC; @@ -87,6 +89,7 @@ static int configfs_fill_super(struct super_block *sb, void *data, int silent) inc_nlink(inode); } else { pr_debug("configfs: could not get root inode\n"); + unlock_kernel(); return -ENOMEM; } @@ -94,12 +97,14 @@ static int configfs_fill_super(struct super_block *sb, void *data, int silent) if (!root) { pr_debug("%s: could not get root dentry!\n",__func__); iput(inode); + unlock_kernel(); return -ENOMEM; } config_group_init(&configfs_root_group); configfs_root_group.cg_item.ci_dentry = root; root->d_fsdata = &configfs_root; sb->s_root = root; + unlock_kernel(); return 0; } diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c index dd3634e..13e696a 100644 --- a/fs/cramfs/inode.c +++ b/fs/cramfs/inode.c @@ -227,11 +227,15 @@ static int cramfs_fill_super(struct super_block *sb, void *data, int silent) struct cramfs_sb_info *sbi; struct inode *root; + lock_kernel(); + sb->s_flags |= MS_RDONLY; sbi = kzalloc(sizeof(struct cramfs_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbi; /* Invalidate the read buffers on mount: think disk change.. */ @@ -308,10 +312,12 @@ static int cramfs_fill_super(struct super_block *sb, void *data, int silent) iput(root); goto out; } + unlock_kernel(); return 0; out: kfree(sbi); sb->s_fs_info = NULL; + unlock_kernel(); return -EINVAL; } diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c index d5f8c96..e206eef 100644 --- a/fs/devpts/inode.c +++ b/fs/devpts/inode.c @@ -24,6 +24,7 @@ #include #include #include +#include /* just for lock_kernel() */ #define DEVPTS_DEFAULT_MODE 0600 /* @@ -363,17 +364,23 @@ static int devpts_get_sb(struct file_system_type *fs_type, struct pts_mount_opts opts; struct super_block *s; + lock_kernel(); + error = parse_mount_options(data, PARSE_MOUNT, &opts); - if (error) + if (error) { + unlock_kernel(); return error; + } if (opts.newinstance) s = sget(fs_type, NULL, set_anon_super, NULL); else s = sget(fs_type, compare_init_pts_sb, set_anon_super, NULL); - if (IS_ERR(s)) + if (IS_ERR(s)) { + unlock_kernel(); return PTR_ERR(s); + } if (!s->s_root) { s->s_flags = flags; @@ -391,6 +398,7 @@ static int devpts_get_sb(struct file_system_type *fs_type, if (error) goto out_dput; + unlock_kernel(); return 0; out_dput: @@ -398,6 +406,7 @@ out_dput: out_undo_sget: deactivate_locked_super(s); + unlock_kernel(); return error; } diff --git a/fs/ecryptfs/main.c b/fs/ecryptfs/main.c index c6ac85d..fdc7bda 100644 --- a/fs/ecryptfs/main.c +++ b/fs/ecryptfs/main.c @@ -600,6 +600,8 @@ static int ecryptfs_get_sb(struct file_system_type *fs_type, int flags, int rc; struct super_block *sb; + lock_kernel(); + rc = get_sb_nodev(fs_type, flags, raw_data, ecryptfs_fill_super, mnt); if (rc < 0) { printk(KERN_ERR "Getting sb failed; rc = [%d]\n", rc); @@ -621,6 +623,7 @@ out_abort: dput(sb->s_root); /* aka mnt->mnt_root, as set by get_sb_nodev() */ deactivate_locked_super(sb); out: + unlock_kernel(); return rc; } diff --git a/fs/efs/super.c b/fs/efs/super.c index f049428..0981141 100644 --- a/fs/efs/super.c +++ b/fs/efs/super.c @@ -249,9 +249,13 @@ static int efs_fill_super(struct super_block *s, void *d, int silent) struct inode *root; int ret = -EINVAL; - sb = kzalloc(sizeof(struct efs_sb_info), GFP_KERNEL); - if (!sb) + lock_kernel(); + + sb = kzalloc(sizeof(struct efs_sb_info), GFP_KERNEL); + if (!sb) { + unlock_kernel(); return -ENOMEM; + } s->s_fs_info = sb; s->s_magic = EFS_SUPER_MAGIC; @@ -319,12 +323,14 @@ static int efs_fill_super(struct super_block *s, void *d, int silent) goto out_no_fs; } + unlock_kernel(); return 0; out_no_fs_ul: out_no_fs: s->s_fs_info = NULL; kfree(sb); + unlock_kernel(); return ret; } diff --git a/fs/exofs/super.c b/fs/exofs/super.c index 9f500de..ea045b8 100644 --- a/fs/exofs/super.c +++ b/fs/exofs/super.c @@ -297,9 +297,13 @@ static int exofs_fill_super(struct super_block *sb, void *data, int silent) struct osd_obj_id obj; int ret; + lock_kernel(); + sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbi; /* use mount options to fill superblock */ @@ -399,6 +403,7 @@ static int exofs_fill_super(struct super_block *sb, void *data, int silent) out: if (or) osd_end_request(or); + unlock_kernel(); return ret; free_sbi: diff --git a/fs/ext2/super.c b/fs/ext2/super.c index 1a9ffee..5af1775 100644 --- a/fs/ext2/super.c +++ b/fs/ext2/super.c @@ -745,15 +745,18 @@ static int ext2_fill_super(struct super_block *sb, void *data, int silent) __le32 features; int err; + lock_kernel(); + + err = -ENOMEM; sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); if (!sbi) - return -ENOMEM; + goto failed_unlock; sbi->s_blockgroup_lock = kzalloc(sizeof(struct blockgroup_lock), GFP_KERNEL); if (!sbi->s_blockgroup_lock) { kfree(sbi); - return -ENOMEM; + goto failed_unlock; } sb->s_fs_info = sbi; sbi->s_sb_block = sb_block; @@ -1063,6 +1066,7 @@ static int ext2_fill_super(struct super_block *sb, void *data, int silent) ext2_warning(sb, __func__, "mounting ext3 filesystem as ext2"); ext2_setup_super (sb, es, sb->s_flags & MS_RDONLY); + unlock_kernel(); return 0; cantfind_ext2: @@ -1086,6 +1090,8 @@ failed_sbi: sb->s_fs_info = NULL; kfree(sbi->s_blockgroup_lock); kfree(sbi); +failed_unlock: + unlock_kernel(); return ret; } diff --git a/fs/ext3/super.c b/fs/ext3/super.c index 7a520a8..38261a5 100644 --- a/fs/ext3/super.c +++ b/fs/ext3/super.c @@ -1568,14 +1568,19 @@ static int ext3_fill_super (struct super_block *sb, void *data, int silent) __le32 features; int err; + lock_kernel(); + sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sbi->s_blockgroup_lock = kzalloc(sizeof(struct blockgroup_lock), GFP_KERNEL); if (!sbi->s_blockgroup_lock) { kfree(sbi); + unlock_kernel(); return -ENOMEM; } sb->s_fs_info = sbi; @@ -1992,6 +1997,7 @@ static int ext3_fill_super (struct super_block *sb, void *data, int silent) "writeback"); lock_kernel(); + unlock_kernel(); return 0; cantfind_ext3: @@ -2022,6 +2028,7 @@ out_fail: kfree(sbi->s_blockgroup_lock); kfree(sbi); lock_kernel(); + unlock_kernel(); return ret; } diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 312211e..9db81d2 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2328,14 +2328,19 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) int err; unsigned int journal_ioprio = DEFAULT_JOURNAL_IOPRIO; + lock_kernel(); + sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sbi->s_blockgroup_lock = kzalloc(sizeof(struct blockgroup_lock), GFP_KERNEL); if (!sbi->s_blockgroup_lock) { kfree(sbi); + unlock_kernel(); return -ENOMEM; } sb->s_fs_info = sbi; @@ -2913,7 +2918,6 @@ no_journal: ext4_msg(sb, KERN_INFO, "mounted filesystem with%s", descr); - lock_kernel(); return 0; cantfind_ext4: @@ -2959,7 +2963,6 @@ out_fail: sb->s_fs_info = NULL; kfree(sbi->s_blockgroup_lock); kfree(sbi); - lock_kernel(); return ret; } diff --git a/fs/fat/namei_msdos.c b/fs/fat/namei_msdos.c index bbc94ae..31dd072 100644 --- a/fs/fat/namei_msdos.c +++ b/fs/fat/namei_msdos.c @@ -662,12 +662,16 @@ static int msdos_fill_super(struct super_block *sb, void *data, int silent) { int res; + lock_kernel(); res = fat_fill_super(sb, data, silent, &msdos_dir_inode_operations, 0); - if (res) + if (res) { + unlock_kernel(); return res; + } sb->s_flags |= MS_NOATIME; sb->s_root->d_op = &msdos_dentry_operations; + unlock_kernel(); return 0; } diff --git a/fs/fat/namei_vfat.c b/fs/fat/namei_vfat.c index f565f24..12961b8 100644 --- a/fs/fat/namei_vfat.c +++ b/fs/fat/namei_vfat.c @@ -1044,15 +1044,19 @@ static int vfat_fill_super(struct super_block *sb, void *data, int silent) { int res; + lock_kernel(); res = fat_fill_super(sb, data, silent, &vfat_dir_inode_operations, 1); - if (res) + if (res) { + unlock_kernel(); return res; + } if (MSDOS_SB(sb)->options.name_check != 's') sb->s_root->d_op = &vfat_ci_dentry_ops; else sb->s_root->d_op = &vfat_dentry_ops; + unlock_kernel(); return 0; } diff --git a/fs/freevxfs/vxfs_super.c b/fs/freevxfs/vxfs_super.c index 1e8af93..b8b7821 100644 --- a/fs/freevxfs/vxfs_super.c +++ b/fs/freevxfs/vxfs_super.c @@ -148,7 +148,7 @@ static int vxfs_remount(struct super_block *sb, int *flags, char *data) * The superblock on success, else %NULL. * * Locking: - * We are under the bkl and @sbp->s_lock. + * We are under @sbp->s_lock. */ static int vxfs_fill_super(struct super_block *sbp, void *dp, int silent) { @@ -159,11 +159,14 @@ static int vxfs_fill_super(struct super_block *sbp, void *dp, int silent) struct inode *root; int ret = -EINVAL; + lock_kernel(); + sbp->s_flags |= MS_RDONLY; infp = kzalloc(sizeof(*infp), GFP_KERNEL); if (!infp) { printk(KERN_WARNING "vxfs: unable to allocate incore superblock\n"); + unlock_kernel(); return -ENOMEM; } @@ -236,6 +239,7 @@ static int vxfs_fill_super(struct super_block *sbp, void *dp, int silent) goto out_free_ilist; } + unlock_kernel(); return 0; out_free_ilist: @@ -245,6 +249,7 @@ out_free_ilist: out: brelse(bp); kfree(infp); + unlock_kernel(); return ret; } diff --git a/fs/fuse/control.c b/fs/fuse/control.c index 3773fd6..8d769f7 100644 --- a/fs/fuse/control.c +++ b/fs/fuse/control.c @@ -10,6 +10,7 @@ #include #include +#include /* just for lock_kernel() */ #define FUSE_CTL_SUPER_MAGIC 0x65735543 @@ -297,9 +298,13 @@ static int fuse_ctl_fill_super(struct super_block *sb, void *data, int silent) struct fuse_conn *fc; int err; + lock_kernel(); + err = simple_fill_super(sb, FUSE_CTL_SUPER_MAGIC, &empty_descr); - if (err) + if (err) { + unlock_kernel(); return err; + } mutex_lock(&fuse_mutex); BUG_ON(fuse_control_sb); @@ -309,10 +314,12 @@ static int fuse_ctl_fill_super(struct super_block *sb, void *data, int silent) if (err) { fuse_control_sb = NULL; mutex_unlock(&fuse_mutex); + unlock_kernel(); return err; } } mutex_unlock(&fuse_mutex); + unlock_kernel(); return 0; } diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index 1a822ce..5690279 100644 --- a/fs/fuse/inode.c +++ b/fs/fuse/inode.c @@ -20,6 +20,7 @@ #include #include #include +#include /* Only for lock_kernel() */ MODULE_AUTHOR("Miklos Szeredi "); MODULE_DESCRIPTION("Filesystem in Userspace"); @@ -919,6 +920,8 @@ static int fuse_fill_super(struct super_block *sb, void *data, int silent) int err; int is_bdev = sb->s_bdev != NULL; + lock_kernel(); + err = -EINVAL; if (sb->s_flags & MS_MANDLOCK) goto err; @@ -1022,6 +1025,7 @@ static int fuse_fill_super(struct super_block *sb, void *data, int silent) fuse_send_init(fc, init_req); + unlock_kernel(); return 0; err_unlock: @@ -1036,6 +1040,7 @@ static int fuse_fill_super(struct super_block *sb, void *data, int silent) err_fput: fput(file); err: + unlock_kernel(); return err; } diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c index 52fb6c0..76415fe 100644 --- a/fs/gfs2/ops_fstype.c +++ b/fs/gfs2/ops_fstype.c @@ -1120,9 +1120,12 @@ static int fill_super(struct super_block *sb, void *data, int silent) struct gfs2_holder mount_gh; int error; + lock_kernel(); + sdp = init_sbd(sb); if (!sdp) { printk(KERN_WARNING "GFS2: can't alloc struct gfs2_sbd\n"); + unlock_kernel(); return -ENOMEM; } @@ -1211,6 +1214,7 @@ static int fill_super(struct super_block *sb, void *data, int silent) gfs2_glock_dq_uninit(&mount_gh); gfs2_online_uevent(sdp); + unlock_kernel(); return 0; fail_threads: @@ -1240,6 +1244,7 @@ fail: gfs2_delete_debugfs_file(sdp); kfree(sdp); sb->s_fs_info = NULL; + unlock_kernel(); return error; } @@ -1268,10 +1273,12 @@ static int gfs2_get_sb_meta(struct file_system_type *fs_type, int flags, struct path path; int error; + lock_kernel(); error = kern_path(dev_name, LOOKUP_FOLLOW, &path); if (error) { printk(KERN_WARNING "GFS2: path_lookup on %s returned error %d\n", dev_name, error); + unlock_kernel(); return error; } s = sget(&gfs2_fs_type, test_meta_super, set_meta_super, @@ -1279,11 +1286,13 @@ static int gfs2_get_sb_meta(struct file_system_type *fs_type, int flags, path_put(&path); if (IS_ERR(s)) { printk(KERN_WARNING "GFS2: gfs2 mount does not exist\n"); + unlock_kernel(); return PTR_ERR(s); } sdp = s->s_fs_info; mnt->mnt_sb = s; mnt->mnt_root = dget(sdp->sd_master_dir); + unlock_kernel(); return 0; } diff --git a/fs/hfs/super.c b/fs/hfs/super.c index f7fcbe4..a2e19ff 100644 --- a/fs/hfs/super.c +++ b/fs/hfs/super.c @@ -381,9 +381,13 @@ static int hfs_fill_super(struct super_block *sb, void *data, int silent) struct inode *root_inode; int res; + lock_kernel(); + sbi = kzalloc(sizeof(struct hfs_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbi; INIT_HLIST_HEAD(&sbi->rsrc_inodes); @@ -429,6 +433,7 @@ static int hfs_fill_super(struct super_block *sb, void *data, int silent) sb->s_root->d_op = &hfs_dentry_operations; /* everything's okay */ + unlock_kernel(); return 0; bail_iput: @@ -437,6 +442,7 @@ bail_no_root: printk(KERN_ERR "hfs: get root inode failed.\n"); bail: hfs_mdb_put(sb); + unlock_kernel(); return res; } diff --git a/fs/hfsplus/super.c b/fs/hfsplus/super.c index 43022f3..824f57a 100644 --- a/fs/hfsplus/super.c +++ b/fs/hfsplus/super.c @@ -312,9 +312,13 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) struct nls_table *nls = NULL; int err = -EINVAL; + lock_kernel(); + sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbi; INIT_HLIST_HEAD(&sbi->rsrc_inodes); @@ -459,11 +463,13 @@ static int hfsplus_fill_super(struct super_block *sb, void *data, int silent) out: unload_nls(sbi->nls); sbi->nls = nls; + unlock_kernel(); return 0; cleanup: hfsplus_put_super(sb); unload_nls(nls); + unlock_kernel(); return err; } diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c index 032604e..5eb2c26 100644 --- a/fs/hostfs/hostfs_kern.c +++ b/fs/hostfs/hostfs_kern.c @@ -968,6 +968,8 @@ static int hostfs_fill_sb_common(struct super_block *sb, void *d, int silent) char *host_root_path, *req_root = d; int err; + lock_kernel(); + sb->s_blocksize = 1024; sb->s_blocksize_bits = 10; sb->s_magic = HOSTFS_SUPER_MAGIC; @@ -1016,6 +1018,7 @@ static int hostfs_fill_sb_common(struct super_block *sb, void *d, int silent) goto out; } + unlock_kernel(); return 0; out_put: @@ -1023,6 +1026,7 @@ out_put: out_free: kfree(host_root_path); out: + unlock_kernel(); return err; } diff --git a/fs/hpfs/super.c b/fs/hpfs/super.c index f2feaa0..a7b348a 100644 --- a/fs/hpfs/super.c +++ b/fs/hpfs/super.c @@ -477,11 +477,15 @@ static int hpfs_fill_super(struct super_block *s, void *options, int silent) int o; + lock_kernel(); + save_mount_options(s, options); sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } s->s_fs_info = sbi; sbi->sb_bmp_dir = NULL; @@ -666,6 +670,7 @@ static int hpfs_fill_super(struct super_block *s, void *options, int silent) root->i_blocks = 5; hpfs_brelse4(&qbh); } + unlock_kernel(); return 0; bail4: brelse(bh2); @@ -677,6 +682,7 @@ bail0: kfree(sbi->sb_cp_table); s->s_fs_info = NULL; kfree(sbi); + unlock_kernel(); return -EINVAL; } diff --git a/fs/hppfs/hppfs.c b/fs/hppfs/hppfs.c index a5089a6..6263973 100644 --- a/fs/hppfs/hppfs.c +++ b/fs/hppfs/hppfs.c @@ -712,6 +712,8 @@ static int hppfs_fill_super(struct super_block *sb, void *d, int silent) struct vfsmount *proc_mnt; int err = -ENOENT; + lock_kernel(); + proc_mnt = do_kern_mount("proc", 0, "proc", NULL); if (IS_ERR(proc_mnt)) goto out; @@ -731,6 +733,7 @@ static int hppfs_fill_super(struct super_block *sb, void *d, int silent) if (!sb->s_root) goto out_iput; + unlock_kernel(); return 0; out_iput: @@ -738,6 +741,7 @@ static int hppfs_fill_super(struct super_block *sb, void *d, int silent) out_mntput: mntput(proc_mnt); out: + unlock_kernel(); return(err); } diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 87a1258..53be2b9 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -32,6 +32,7 @@ #include #include #include +#include /* Only for lock_kernel() */ #include @@ -824,6 +825,7 @@ hugetlbfs_fill_super(struct super_block *sb, void *data, int silent) struct hugetlbfs_config config; struct hugetlbfs_sb_info *sbinfo; + lock_kernel(); save_mount_options(sb, data); config.nr_blocks = -1; /* No limit on size by default */ @@ -833,12 +835,16 @@ hugetlbfs_fill_super(struct super_block *sb, void *data, int silent) config.mode = 0755; config.hstate = &default_hstate; ret = hugetlbfs_parse_options(data, &config); - if (ret) + if (ret) { + unlock_kernel(); return ret; + } sbinfo = kmalloc(sizeof(struct hugetlbfs_sb_info), GFP_KERNEL); - if (!sbinfo) + if (!sbinfo) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbinfo; sbinfo->hstate = config.hstate; spin_lock_init(&sbinfo->stat_lock); @@ -863,9 +869,11 @@ hugetlbfs_fill_super(struct super_block *sb, void *data, int silent) goto out_free; } sb->s_root = root; + unlock_kernel(); return 0; out_free: kfree(sbinfo); + unlock_kernel(); return -ENOMEM; } diff --git a/fs/isofs/inode.c b/fs/isofs/inode.c index 6b4dcd4..7c501d5 100644 --- a/fs/isofs/inode.c +++ b/fs/isofs/inode.c @@ -571,11 +571,15 @@ static int isofs_fill_super(struct super_block *s, void *data, int silent) int table, error = -EINVAL; unsigned int vol_desc_start; + lock_kernel(); + save_mount_options(s, data); sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } s->s_fs_info = sbi; if (!parse_options((char *)data, &opt)) @@ -895,6 +899,7 @@ root_found: kfree(opt.iocharset); + unlock_kernel(); return 0; /* @@ -934,6 +939,7 @@ out_freesbi: kfree(opt.iocharset); kfree(sbi); s->s_fs_info = NULL; + unlock_kernel(); return error; } diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c index 9a80e8e..622bd51 100644 --- a/fs/jffs2/super.c +++ b/fs/jffs2/super.c @@ -148,14 +148,19 @@ static const struct super_operations jffs2_super_operations = static int jffs2_fill_super(struct super_block *sb, void *data, int silent) { struct jffs2_sb_info *c; + int ret; + + lock_kernel(); D1(printk(KERN_DEBUG "jffs2_get_sb_mtd():" " New superblock for device %d (\"%s\")\n", sb->s_mtd->index, sb->s_mtd->name)); c = kzalloc(sizeof(*c), GFP_KERNEL); - if (!c) + if (!c) { + unlock_kernel(); return -ENOMEM; + } c->mtd = sb->s_mtd; c->os_priv = sb; @@ -177,7 +182,9 @@ static int jffs2_fill_super(struct super_block *sb, void *data, int silent) #ifdef CONFIG_JFFS2_FS_POSIX_ACL sb->s_flags |= MS_POSIXACL; #endif - return jffs2_do_fill_super(sb, data, silent); + ret = jffs2_do_fill_super(sb, data, silent); + unlock_kernel(); + return ret; } static int jffs2_get_sb(struct file_system_type *fs_type, diff --git a/fs/jfs/super.c b/fs/jfs/super.c index 2234c73..329d7b6 100644 --- a/fs/jfs/super.c +++ b/fs/jfs/super.c @@ -425,14 +425,20 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent) s64 newLVSize = 0; int flag, ret = -EINVAL; + lock_kernel(); + jfs_info("In jfs_read_super: s_flags=0x%lx", sb->s_flags); - if (!new_valid_dev(sb->s_bdev->bd_dev)) + if (!new_valid_dev(sb->s_bdev->bd_dev)) { + unlock_kernel(); return -EOVERFLOW; + } sbi = kzalloc(sizeof (struct jfs_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbi; sbi->sb = sb; sbi->uid = sbi->gid = sbi->umask = -1; @@ -442,6 +448,7 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent) if (!parse_options((char *) data, sb, &newLVSize, &flag)) { kfree(sbi); + unlock_kernel(); return -EINVAL; } sbi->flag = flag; @@ -452,6 +459,7 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent) if (newLVSize) { printk(KERN_ERR "resize option for remount only\n"); + unlock_kernel(); return -EINVAL; } @@ -527,6 +535,7 @@ static int jfs_fill_super(struct super_block *sb, void *data, int silent) sb->s_maxbytes = min(((u64) PAGE_CACHE_SIZE << 32) - 1, sb->s_maxbytes); #endif sb->s_time_gran = 1; + unlock_kernel(); return 0; out_no_root: @@ -548,6 +557,7 @@ out_kfree: if (sbi->nls_tab) unload_nls(sbi->nls_tab); kfree(sbi); + unlock_kernel(); return ret; } diff --git a/fs/libfs.c b/fs/libfs.c index 219576c..3484040 100644 --- a/fs/libfs.c +++ b/fs/libfs.c @@ -11,6 +11,7 @@ #include #include #include +#include /* Only for lock_kernel() */ #include @@ -422,6 +423,8 @@ int simple_fill_super(struct super_block *s, int magic, struct tree_descr *files struct dentry *dentry; int i; + lock_kernel(); + s->s_blocksize = PAGE_CACHE_SIZE; s->s_blocksize_bits = PAGE_CACHE_SHIFT; s->s_magic = magic; @@ -429,8 +432,10 @@ int simple_fill_super(struct super_block *s, int magic, struct tree_descr *files s->s_time_gran = 1; inode = new_inode(s); - if (!inode) + if (!inode) { + unlock_kernel(); return -ENOMEM; + } /* * because the root inode is 1, the files array must not contain an * entry at index 1 @@ -444,6 +449,7 @@ int simple_fill_super(struct super_block *s, int magic, struct tree_descr *files root = d_alloc_root(inode); if (!root) { iput(inode); + unlock_kernel(); return -ENOMEM; } for (i = 0; !files->name || files->name[0]; i++, files++) { @@ -469,10 +475,12 @@ int simple_fill_super(struct super_block *s, int magic, struct tree_descr *files d_add(dentry, inode); } s->s_root = root; + unlock_kernel(); return 0; out: d_genocide(root); dput(root); + unlock_kernel(); return -ENOMEM; } diff --git a/fs/minix/inode.c b/fs/minix/inode.c index 74ea82d..b8aa0a6 100644 --- a/fs/minix/inode.c +++ b/fs/minix/inode.c @@ -147,9 +147,13 @@ static int minix_fill_super(struct super_block *s, void *data, int silent) struct minix_sb_info *sbi; int ret = -EINVAL; + lock_kernel(); + sbi = kzalloc(sizeof(struct minix_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } s->s_fs_info = sbi; BUILD_BUG_ON(32 != sizeof (struct minix_inode)); @@ -265,6 +269,7 @@ static int minix_fill_super(struct super_block *s, void *data, int silent) else if (sbi->s_mount_state & MINIX_ERROR_FS) printk("MINIX-fs: mounting file system with errors, " "running fsck is recommended\n"); + unlock_kernel(); return 0; out_iput: @@ -314,6 +319,7 @@ out_bad_sb: out: s->s_fs_info = NULL; kfree(sbi); + unlock_kernel(); return ret; } diff --git a/fs/namespace.c b/fs/namespace.c index bdc3cb4..3f95497 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -1647,9 +1647,7 @@ static int do_new_mount(struct path *path, char *type, int flags, if (!capable(CAP_SYS_ADMIN)) return -EPERM; - lock_kernel(); mnt = do_kern_mount(type, flags, name, data); - unlock_kernel(); if (IS_ERR(mnt)) return PTR_ERR(mnt); diff --git a/fs/ncpfs/inode.c b/fs/ncpfs/inode.c index cf98da1..a020d86 100644 --- a/fs/ncpfs/inode.c +++ b/fs/ncpfs/inode.c @@ -445,10 +445,14 @@ static int ncp_fill_super(struct super_block *sb, void *raw_data, int silent) #endif struct ncp_entry_info finfo; + lock_kernel(); + data.wdog_pid = NULL; server = kzalloc(sizeof(struct ncp_server), GFP_KERNEL); - if (!server) + if (!server) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = server; error = -EFAULT; @@ -695,6 +699,7 @@ static int ncp_fill_super(struct super_block *sb, void *raw_data, int silent) if (!sb->s_root) goto out_no_root; sb->s_root->d_op = &ncp_root_dentry_operations; + unlock_kernel(); return 0; out_no_root: @@ -729,6 +734,7 @@ out: put_pid(data.wdog_pid); sb->s_fs_info = NULL; kfree(server); + unlock_kernel(); return error; } diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 90be551..1f97aad 100644 --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -1877,6 +1877,8 @@ nfs_remount(struct super_block *sb, int *flags, char *raw_data) options->version <= 6)))) return 0; + lock_kernel(); + data = kzalloc(sizeof(*data), GFP_KERNEL); if (data == NULL) return -ENOMEM; @@ -2184,6 +2186,7 @@ out: out_free_fh: kfree(mntfh); kfree(data); + unlock_kernel(); return error; out_err_nosb: @@ -2227,6 +2230,8 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags, }; int error; + lock_kernel(); + dprintk("--> nfs_xdev_get_sb()\n"); /* create a new volume representation */ @@ -2281,17 +2286,20 @@ static int nfs_xdev_get_sb(struct file_system_type *fs_type, int flags, security_sb_clone_mnt_opts(data->sb, s); dprintk("<-- nfs_xdev_get_sb() = 0\n"); + unlock_kernel(); return 0; out_err_nosb: nfs_free_server(server); out_err_noserver: dprintk("<-- nfs_xdev_get_sb() = %d [error]\n", error); + unlock_kernel(); return error; error_splat_super: deactivate_locked_super(s); dprintk("<-- nfs_xdev_get_sb() = %d [splat]\n", error); + unlock_kernel(); return error; } @@ -2475,6 +2483,8 @@ static int nfs4_remote_get_sb(struct file_system_type *fs_type, }; int error = -ENOMEM; + lock_kernel(); + mntfh = kzalloc(sizeof(*mntfh), GFP_KERNEL); if (data == NULL || mntfh == NULL) goto out_free_fh; @@ -2534,6 +2544,7 @@ out: security_free_mnt_opts(&data->lsm_opts); out_free_fh: kfree(mntfh); + unlock_kernel(); return error; out_free: @@ -2794,6 +2805,8 @@ static int nfs4_remote_referral_get_sb(struct file_system_type *fs_type, }; int error; + lock_kernel(); + dprintk("--> nfs4_referral_get_sb()\n"); /* create a new volume representation */ @@ -2847,17 +2860,20 @@ static int nfs4_remote_referral_get_sb(struct file_system_type *fs_type, security_sb_clone_mnt_opts(data->sb, s); dprintk("<-- nfs4_referral_get_sb() = 0\n"); + unlock_kernel(); return 0; out_err_nosb: nfs_free_server(server); out_err_noserver: dprintk("<-- nfs4_referral_get_sb() = %d [error]\n", error); + unlock_kernel(); return error; error_splat_super: deactivate_locked_super(s); dprintk("<-- nfs4_referral_get_sb() = %d [splat]\n", error); + unlock_kernel(); return error; } @@ -2873,6 +2889,8 @@ static int nfs4_referral_get_sb(struct file_system_type *fs_type, struct vfsmount *root_mnt; int error; + lock_kernel(); + dprintk("--> nfs4_referral_get_sb()\n"); export_path = data->mnt_path; @@ -2890,6 +2908,7 @@ static int nfs4_referral_get_sb(struct file_system_type *fs_type, out: dprintk("<-- nfs4_referral_get_sb() = %d%s\n", error, error != 0 ? " [error]" : ""); + unlock_kernel(); return error; } diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c index 5c01fc1..dcaef52 100644 --- a/fs/nfsd/nfsctl.c +++ b/fs/nfsd/nfsctl.c @@ -1347,7 +1347,12 @@ static int nfsd_fill_super(struct super_block * sb, void * data, int silent) #endif /* last one */ {""} }; - return simple_fill_super(sb, 0x6e667364, nfsd_files); + int ret; + + lock_kernel(); + ret = simple_fill_super(sb, 0x6e667364, nfsd_files); + unlock_kernel(); + return ret; } static int nfsd_get_sb(struct file_system_type *fs_type, diff --git a/fs/nilfs2/super.c b/fs/nilfs2/super.c index 644e667..3448ec3 100644 --- a/fs/nilfs2/super.c +++ b/fs/nilfs2/super.c @@ -1059,9 +1059,13 @@ nilfs_get_sb(struct file_system_type *fs_type, int flags, struct the_nilfs *nilfs; int err, need_to_close = 1; + lock_kernel(); + sd.bdev = open_bdev_exclusive(dev_name, flags, fs_type); - if (IS_ERR(sd.bdev)) + if (IS_ERR(sd.bdev)) { + unlock_kernel(); return PTR_ERR(sd.bdev); + } /* * To get mount instance using sget() vfs-routine, NILFS needs @@ -1142,6 +1146,7 @@ nilfs_get_sb(struct file_system_type *fs_type, int flags, if (need_to_close) close_bdev_exclusive(sd.bdev, flags); simple_set_mnt(mnt, s); + unlock_kernel(); return 0; failed_unlock: @@ -1150,6 +1155,7 @@ nilfs_get_sb(struct file_system_type *fs_type, int flags, failed: close_bdev_exclusive(sd.bdev, flags); + unlock_kernel(); return err; cancel_new: @@ -1163,6 +1169,7 @@ nilfs_get_sb(struct file_system_type *fs_type, int flags, * We must finish all post-cleaning before this call; * put_nilfs() needs the block device. */ + unlock_kernel(); return err; } diff --git a/fs/ntfs/super.c b/fs/ntfs/super.c index 80b0477..ab09c02 100644 --- a/fs/ntfs/super.c +++ b/fs/ntfs/super.c @@ -2723,6 +2723,8 @@ static int ntfs_fill_super(struct super_block *sb, void *opt, const int silent) struct inode *tmp_ino; int blocksize, result; + lock_kernel(); + /* * We do a pretty difficult piece of bootstrap by reading the * MFT (and other metadata) from disk into memory. We'll only @@ -2746,6 +2748,7 @@ static int ntfs_fill_super(struct super_block *sb, void *opt, const int silent) ntfs_error(sb, "Allocation of NTFS volume structure " "failed. Aborting mount..."); lockdep_on(); + unlock_kernel(); return -ENOMEM; } /* Initialize ntfs_volume structure. */ @@ -2933,6 +2936,7 @@ static int ntfs_fill_super(struct super_block *sb, void *opt, const int silent) sb->s_export_op = &ntfs_export_ops; lock_kernel(); lockdep_on(); + unlock_kernel(); return 0; } ntfs_error(sb, "Failed to allocate root directory."); @@ -3053,6 +3057,7 @@ err_out_now: kfree(vol); ntfs_debug("Failed, returning -EINVAL."); lockdep_on(); + unlock_kernel(); return -EINVAL; } diff --git a/fs/ocfs2/dlm/dlmfs.c b/fs/ocfs2/dlm/dlmfs.c index 02bf178..58ce813 100644 --- a/fs/ocfs2/dlm/dlmfs.c +++ b/fs/ocfs2/dlm/dlmfs.c @@ -528,21 +528,27 @@ static int dlmfs_fill_super(struct super_block * sb, struct inode * inode; struct dentry * root; + lock_kernel(); + sb->s_maxbytes = MAX_LFS_FILESIZE; sb->s_blocksize = PAGE_CACHE_SIZE; sb->s_blocksize_bits = PAGE_CACHE_SHIFT; sb->s_magic = DLMFS_MAGIC; sb->s_op = &dlmfs_ops; inode = dlmfs_get_root_inode(sb); - if (!inode) + if (!inode) { + unlock_kernel(); return -ENOMEM; + } root = d_alloc_root(inode); if (!root) { iput(inode); + unlock_kernel(); return -ENOMEM; } sb->s_root = root; + unlock_kernel(); return 0; } diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c index c0e48ae..fab815f 100644 --- a/fs/ocfs2/super.c +++ b/fs/ocfs2/super.c @@ -986,6 +986,8 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) char nodestr[8]; struct ocfs2_blockcheck_stats stats; + lock_kernel(); + mlog_entry("%p, %p, %i", sb, data, silent); if (!ocfs2_parse_options(sb, data, &parsed_options, 0)) { @@ -1172,6 +1174,7 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) atomic_set(&osb->vol_state, VOLUME_DISABLED); wake_up(&osb->osb_mount_event); mlog_exit(status); + unlock_kernel(); return status; } } @@ -1186,6 +1189,7 @@ static int ocfs2_fill_super(struct super_block *sb, void *data, int silent) ocfs2_orphan_scan_start(osb); mlog_exit(status); + unlock_kernel(); return status; read_super_error: @@ -1201,6 +1205,7 @@ read_super_error: } mlog_exit(status); + unlock_kernel(); return status; } diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c index f3b7c15..ddfbb22 100644 --- a/fs/omfs/inode.c +++ b/fs/omfs/inode.c @@ -416,11 +416,15 @@ static int omfs_fill_super(struct super_block *sb, void *data, int silent) sector_t start; int ret = -EINVAL; + lock_kernel(); + save_mount_options(sb, (char *) data); sbi = kzalloc(sizeof(struct omfs_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbi; @@ -525,6 +529,7 @@ out_brelse_bh2: out_brelse_bh: brelse(bh); end: + unlock_kernel(); return ret; } diff --git a/fs/openpromfs/inode.c b/fs/openpromfs/inode.c index ffcd04f..50dc4be 100644 --- a/fs/openpromfs/inode.c +++ b/fs/openpromfs/inode.c @@ -386,6 +386,8 @@ static int openprom_fill_super(struct super_block *s, void *data, int silent) struct op_inode_info *oi; int ret; + lock_kernel(); + s->s_flags |= MS_NOATIME; s->s_blocksize = 1024; s->s_blocksize_bits = 10; @@ -405,6 +407,7 @@ static int openprom_fill_super(struct super_block *s, void *data, int silent) s->s_root = d_alloc_root(root_inode); if (!s->s_root) goto out_no_root_dentry; + unlock_kernel(); return 0; out_no_root_dentry: @@ -412,6 +415,7 @@ out_no_root_dentry: ret = -ENOMEM; out_no_root: printk("openprom_fill_super: get root inode failed\n"); + unlock_kernel(); return ret; } diff --git a/fs/proc/root.c b/fs/proc/root.c index b080b79..6384680 100644 --- a/fs/proc/root.c +++ b/fs/proc/root.c @@ -18,6 +18,7 @@ #include #include #include +#include /* For lock_kernel() only */ #include "internal.h" @@ -43,6 +44,8 @@ static int proc_get_sb(struct file_system_type *fs_type, struct pid_namespace *ns; struct proc_inode *ei; + lock_kernel(); + if (proc_mnt) { /* Seed the root directory with a pid so it doesn't need * to be special in base.c. I would do this earlier but @@ -60,14 +63,17 @@ static int proc_get_sb(struct file_system_type *fs_type, ns = current->nsproxy->pid_ns; sb = sget(fs_type, proc_test_super, proc_set_super, ns); - if (IS_ERR(sb)) + if (IS_ERR(sb)) { + unlock_kernel(); return PTR_ERR(sb); + } if (!sb->s_root) { sb->s_flags = flags; err = proc_fill_super(sb); if (err) { deactivate_locked_super(sb); + unlock_kernel(); return err; } @@ -83,6 +89,7 @@ static int proc_get_sb(struct file_system_type *fs_type, } simple_set_mnt(mnt, sb); + unlock_kernel(); return 0; } diff --git a/fs/qnx4/inode.c b/fs/qnx4/inode.c index d2cd179..18640ce 100644 --- a/fs/qnx4/inode.c +++ b/fs/qnx4/inode.c @@ -253,9 +253,13 @@ static int qnx4_fill_super(struct super_block *s, void *data, int silent) struct qnx4_sb_info *qs; int ret = -EINVAL; + lock_kernel(); + qs = kzalloc(sizeof(struct qnx4_sb_info), GFP_KERNEL); - if (!qs) + if (!qs) { + unlock_kernel(); return -ENOMEM; + } s->s_fs_info = qs; sb_set_blocksize(s, QNX4_BLOCK_SIZE); @@ -303,6 +307,7 @@ static int qnx4_fill_super(struct super_block *s, void *data, int silent) brelse(bh); + unlock_kernel(); return 0; outi: @@ -312,6 +317,7 @@ static int qnx4_fill_super(struct super_block *s, void *data, int silent) outnobh: kfree(qs); s->s_fs_info = NULL; + unlock_kernel(); return ret; } diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c index a6090aa..9b3983f 100644 --- a/fs/ramfs/inode.c +++ b/fs/ramfs/inode.c @@ -35,6 +35,7 @@ #include #include #include +#include /* Only for lock_kernel() */ #include #include "internal.h" @@ -220,6 +221,8 @@ static int ramfs_fill_super(struct super_block * sb, void * data, int silent) struct dentry *root; int err; + lock_kernel(); + save_mount_options(sb, data); fsi = kzalloc(sizeof(struct ramfs_fs_info), GFP_KERNEL); @@ -253,11 +256,13 @@ static int ramfs_fill_super(struct super_block * sb, void * data, int silent) goto fail; } + unlock_kernel(); return 0; fail: kfree(fsi); sb->s_fs_info = NULL; iput(inode); + unlock_kernel(); return err; } diff --git a/fs/reiserfs/super.c b/fs/reiserfs/super.c index f0ad05f..f32bf62 100644 --- a/fs/reiserfs/super.c +++ b/fs/reiserfs/super.c @@ -1608,6 +1608,8 @@ static int reiserfs_fill_super(struct super_block *s, void *data, int silent) char *qf_names[MAXQUOTAS] = {}; unsigned int qfmt = 0; + lock_kernel(); + save_mount_options(s, data); sbi = kzalloc(sizeof(struct reiserfs_sb_info), GFP_KERNEL); @@ -1852,6 +1854,7 @@ static int reiserfs_fill_super(struct super_block *s, void *data, int silent) init_waitqueue_head(&(sbi->s_wait)); spin_lock_init(&sbi->bitmap_lock); + unlock_kernel(); return (0); error: @@ -1872,6 +1875,7 @@ error: kfree(sbi); s->s_fs_info = NULL; + unlock_kernel(); return errval; } diff --git a/fs/romfs/super.c b/fs/romfs/super.c index c117fa8..7342617 100644 --- a/fs/romfs/super.c +++ b/fs/romfs/super.c @@ -468,6 +468,8 @@ static int romfs_fill_super(struct super_block *sb, void *data, int silent) size_t len; int ret; + lock_kernel(); + #ifdef CONFIG_BLOCK if (!sb->s_mtd) { sb_set_blocksize(sb, ROMBSIZE); @@ -484,8 +486,10 @@ static int romfs_fill_super(struct super_block *sb, void *data, int silent) /* read the image superblock and check it */ rsb = kmalloc(512, GFP_KERNEL); - if (!rsb) + if (!rsb) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = (void *) 512; ret = romfs_dev_read(sb, 0, rsb, 512); @@ -535,15 +539,18 @@ static int romfs_fill_super(struct super_block *sb, void *data, int silent) if (!sb->s_root) goto error_i; + unlock_kernel(); return 0; error_i: iput(root); error: + unlock_kernel(); return -EINVAL; error_rsb_inval: ret = -EINVAL; error_rsb: + unlock_kernel(); return ret; } diff --git a/fs/smbfs/inode.c b/fs/smbfs/inode.c index 1c4c8f0..c3c9044 100644 --- a/fs/smbfs/inode.c +++ b/fs/smbfs/inode.c @@ -500,6 +500,8 @@ static int smb_fill_super(struct super_block *sb, void *raw_data, int silent) void *mem; static int warn_count; + lock_kernel(); + if (warn_count < 5) { warn_count++; printk(KERN_EMERG "smbfs is deprecated and will be removed" @@ -615,6 +617,7 @@ static int smb_fill_super(struct super_block *sb, void *raw_data, int silent) smb_new_dentry(sb->s_root); + unlock_kernel(); return 0; out_no_root: @@ -635,9 +638,11 @@ out_wrong_data: out_no_data: printk(KERN_ERR "smb_fill_super: missing data argument\n"); out_fail: + unlock_kernel(); return -EINVAL; out_no_server: printk(KERN_ERR "smb_fill_super: cannot allocate struct smb_sb_info\n"); + unlock_kernel(); return -ENOMEM; } diff --git a/fs/squashfs/super.c b/fs/squashfs/super.c index 6c197ef..23cea83 100644 --- a/fs/squashfs/super.c +++ b/fs/squashfs/super.c @@ -78,11 +78,14 @@ static int squashfs_fill_super(struct super_block *sb, void *data, int silent) u64 lookup_table_start; int err; + lock_kernel(); + TRACE("Entered squashfs_fill_superblock\n"); sb->s_fs_info = kzalloc(sizeof(*msblk), GFP_KERNEL); if (sb->s_fs_info == NULL) { ERROR("Failed to allocate squashfs_sb_info\n"); + unlock_kernel(); return -ENOMEM; } msblk = sb->s_fs_info; @@ -286,6 +289,7 @@ allocate_root: TRACE("Leaving squashfs_fill_super\n"); kfree(sblk); + unlock_kernel(); return 0; failed_mount: @@ -299,12 +303,14 @@ failed_mount: kfree(sb->s_fs_info); sb->s_fs_info = NULL; kfree(sblk); + unlock_kernel(); return err; failure: kfree(msblk->stream.workspace); kfree(sb->s_fs_info); sb->s_fs_info = NULL; + unlock_kernel(); return -ENOMEM; } diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c index 4974995..2e5a870 100644 --- a/fs/sysfs/mount.c +++ b/fs/sysfs/mount.c @@ -18,6 +18,7 @@ #include #include #include +#include /* Only for lock_kernel() */ #include "sysfs.h" @@ -45,6 +46,8 @@ static int sysfs_fill_super(struct super_block *sb, void *data, int silent) struct inode *inode; struct dentry *root; + lock_kernel(); + sb->s_blocksize = PAGE_CACHE_SIZE; sb->s_blocksize_bits = PAGE_CACHE_SHIFT; sb->s_magic = SYSFS_MAGIC; @@ -58,6 +61,7 @@ static int sysfs_fill_super(struct super_block *sb, void *data, int silent) mutex_unlock(&sysfs_mutex); if (!inode) { pr_debug("sysfs: could not get root inode\n"); + unlock_kernel(); return -ENOMEM; } @@ -66,10 +70,12 @@ static int sysfs_fill_super(struct super_block *sb, void *data, int silent) if (!root) { pr_debug("%s: could not get root dentry!\n",__func__); iput(inode); + unlock_kernel(); return -ENOMEM; } root->d_fsdata = &sysfs_root; sb->s_root = root; + unlock_kernel(); return 0; } diff --git a/fs/sysv/super.c b/fs/sysv/super.c index 5a903da..145d949 100644 --- a/fs/sysv/super.c +++ b/fs/sysv/super.c @@ -357,7 +357,9 @@ static int sysv_fill_super(struct super_block *sb, void *data, int silent) struct sysv_sb_info *sbi; unsigned long blocknr; int size = 0, i; - + + lock_kernel(); + BUILD_BUG_ON(1024 != sizeof (struct xenix_super_block)); BUILD_BUG_ON(512 != sizeof (struct sysv4_super_block)); BUILD_BUG_ON(512 != sizeof (struct sysv2_super_block)); @@ -365,8 +367,10 @@ static int sysv_fill_super(struct super_block *sb, void *data, int silent) BUILD_BUG_ON(64 != sizeof (struct sysv_inode)); sbi = kzalloc(sizeof(struct sysv_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sbi->s_sb = sb; sbi->s_block_base = 0; @@ -409,8 +413,10 @@ static int sysv_fill_super(struct super_block *sb, void *data, int silent) if (bh && bh1) { sbi->s_bh1 = bh1; sbi->s_bh2 = bh; - if (complete_read_super(sb, silent, size)) + if (complete_read_super(sb, silent, size)) { + unlock_kernel(); return 0; + } } brelse(bh1); @@ -419,6 +425,7 @@ static int sysv_fill_super(struct super_block *sb, void *data, int silent) printk("oldfs: cannot read superblock\n"); failed: kfree(sbi); + unlock_kernel(); return -EINVAL; Eunknown: @@ -442,14 +449,18 @@ static int v7_fill_super(struct super_block *sb, void *data, int silent) struct v7_super_block *v7sb; struct sysv_inode *v7i; + lock_kernel(); + if (440 != sizeof (struct v7_super_block)) panic("V7 FS: bad super-block size"); if (64 != sizeof (struct sysv_inode)) panic("sysv fs: bad i-node size"); sbi = kzalloc(sizeof(struct sysv_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sbi->s_sb = sb; sbi->s_block_base = 0; @@ -487,13 +498,16 @@ static int v7_fill_super(struct super_block *sb, void *data, int silent) sbi->s_bh1 = bh; sbi->s_bh2 = bh; - if (complete_read_super(sb, silent, 1)) + if (complete_read_super(sb, silent, 1)) { + unlock_kernel(); return 0; + } failed: brelse(bh2); brelse(bh); kfree(sbi); + unlock_kernel(); return -EINVAL; } diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index 333e181..04a0fc9 100644 --- a/fs/ubifs/super.c +++ b/fs/ubifs/super.c @@ -2029,6 +2029,8 @@ static int ubifs_get_sb(struct file_system_type *fs_type, int flags, struct super_block *sb; int err; + lock_kernel(); + dbg_gen("name %s, flags %#x", name, flags); /* @@ -2040,6 +2042,7 @@ static int ubifs_get_sb(struct file_system_type *fs_type, int flags, if (IS_ERR(ubi)) { ubifs_err("cannot open \"%s\", error %d", name, (int)PTR_ERR(ubi)); + unlock_kernel(); return PTR_ERR(ubi); } ubi_get_volume_info(ubi, &vi); @@ -2077,12 +2080,14 @@ static int ubifs_get_sb(struct file_system_type *fs_type, int flags, ubi_close_volume(ubi); simple_set_mnt(mnt, sb); + unlock_kernel(); return 0; out_deact: deactivate_locked_super(sb); out_close: ubi_close_volume(ubi); + unlock_kernel(); return err; } diff --git a/fs/udf/super.c b/fs/udf/super.c index 9d1b8c2..fa6f8db 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -1866,6 +1866,8 @@ static int udf_fill_super(struct super_block *sb, void *options, int silent) struct kernel_lb_addr rootdir, fileset; struct udf_sb_info *sbi; + lock_kernel(); + uopt.flags = (1 << UDF_FLAG_USE_AD_IN_ICB) | (1 << UDF_FLAG_STRICT); uopt.uid = -1; uopt.gid = -1; @@ -1874,8 +1876,10 @@ static int udf_fill_super(struct super_block *sb, void *options, int silent) uopt.dmode = UDF_INVALID_MODE; sbi = kzalloc(sizeof(struct udf_sb_info), GFP_KERNEL); - if (!sbi) + if (!sbi) { + unlock_kernel(); return -ENOMEM; + } sb->s_fs_info = sbi; @@ -2021,6 +2025,7 @@ static int udf_fill_super(struct super_block *sb, void *options, int silent) goto error_out; } sb->s_maxbytes = MAX_LFS_FILESIZE; + unlock_kernel(); return 0; error_out: @@ -2041,6 +2046,7 @@ error_out: kfree(sbi); sb->s_fs_info = NULL; + unlock_kernel(); return -EINVAL; } diff --git a/fs/ufs/super.c b/fs/ufs/super.c index 5faed79..31ad198 100644 --- a/fs/ufs/super.c +++ b/fs/ufs/super.c @@ -646,6 +646,8 @@ static int ufs_fill_super(struct super_block *sb, void *data, int silent) unsigned maxsymlen; int ret = -EINVAL; + lock_kernel(); + uspi = NULL; ubh = NULL; flags = 0; @@ -1107,6 +1109,7 @@ magic_found: goto failed; UFSD("EXIT\n"); + unlock_kernel(); return 0; dalloc_failed: @@ -1118,10 +1121,12 @@ failed: kfree(sbi); sb->s_fs_info = NULL; UFSD("EXIT (FAILED)\n"); + unlock_kernel(); return ret; failed_nomem: UFSD("EXIT (NOMEM)\n"); + unlock_kernel(); return -ENOMEM; } diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c index 18a4b8e..7426166 100644 --- a/fs/xfs/linux-2.6/xfs_super.c +++ b/fs/xfs/linux-2.6/xfs_super.c @@ -1412,6 +1412,8 @@ xfs_fs_fill_super( int flags = 0, error = ENOMEM; char *mtpt = NULL; + lock_kernel(); + mp = kzalloc(sizeof(struct xfs_mount), GFP_KERNEL); if (!mp) goto out; @@ -1506,6 +1508,7 @@ xfs_fs_fill_super( kfree(mtpt); xfs_itrace_exit(XFS_I(sb->s_root->d_inode)); + unlock_kernel(); return 0; out_filestream_unmount: @@ -1522,6 +1525,7 @@ xfs_fs_fill_super( kfree(mtpt); kfree(mp); out: + unlock_kernel(); return -error; fail_vnrele: -- 1.6.4.2 From michael.monnerie@is.it-management.at Mon Nov 2 05:05:24 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2B5MVZ035634 for ; Mon, 2 Nov 2009 05:05:24 -0600 X-ASG-Debug-ID: 1257159931-388400d80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 082BE14CD492 for ; Mon, 2 Nov 2009 03:05:31 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id dESBNfPtkuUiHIFw for ; Mon, 02 Nov 2009 03:05:31 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id BD780C3AB09 for ; Mon, 2 Nov 2009 12:05:28 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 7F71940016F for ; Mon, 2 Nov 2009 12:05:28 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files Date: Mon, 2 Nov 2009 12:05:27 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <4AEC2CF4.8040703@aol.com> <4AEC4BAA.20606@aol.com> <20091031174836.3fc9505b@galadriel.home> In-Reply-To: <20091031174836.3fc9505b@galadriel.home> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911021205.28006@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257159933 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13520 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Samstag 31 Oktober 2009 Emmanuel Florac wrote: > Another trick is to mkfs the drive with su and sw matching the > underlying RAID, for instance for a 15 drives RAID6 with 64K stripe > use something like (beware, unverified syntax from memory): > > mkfs -t xfs -d su=65536,sw=15 /dev/sdXX I believe for a 15 drive RAID-6, where 2 disks are used for redundancy, the correct mkfs would be: mkfs -t xfs -d su=65536,sw=13 /dev/sdXX That is, you tell XFS how many *data disks* there are, not how many disks the RAID uses, because the important thing is that XFS should distribute it's metadata over different disks. One thing you could try: Each 2 minutes, create a new dir and store new files there. It could well be that XFS becomes slower when having a certain amount of files in a dir. If you change the dir, and now everything writes without drops, that should be the problem. If you can't change the dir for your application, start a small batch job that moves the files to another dir, or removes them. Another thing to try is if it would help to turn disk cache writes *on*, despite all warnings if the FAQ. That could also give an idea where to look at next time. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From info@globalnetstore.com Mon Nov 2 11:03:29 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=BAYES_50,HTML_IMAGE_ONLY_32, HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2H3Sei072780 for ; Mon, 2 Nov 2009 11:03:28 -0600 X-ASG-Debug-ID: 1257181419-1a2900870000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail2.globalnetstore.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 4961314CF4A8 for ; Mon, 2 Nov 2009 09:03:39 -0800 (PST) Received: from mail2.globalnetstore.com (mail2.globalnetstore.com [208.53.152.59]) by cuda.sgi.com with SMTP id XCmzRQXozIjqR3hV for ; Mon, 02 Nov 2009 09:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=globalnetstore.com; s=dkim; t=1257181419; bh=u4ShdIYJA9XzawYaf4A5PT9iGcs=; h=To:From:Reply-To:Subject:Date:MIME-Version:List-Unsubscribe: Content-type; b=WgzfShsWG/wN64zJbg2J99dx/eolVjfz/4GV/n0AmwMtylu3w53lW3XCSLsj7W3zT iK38kCJkplnM1ipqnrcD3HiPFV6EgZp/Iyx9qQ4HaqKYyldw1GhsSCg3qBJNODzC94 iWvDR/FvIQrnWeU4+oXuIVU15ZODDUopLPQIqIr4= To: "linux-xfs" From: "Stathmore's Who's Who" Reply-To: X-ASG-Orig-Subj: Jakob - Your Recent Nomination to Strathmore's Who's Who Subject: Jakob - Your Recent Nomination to Strathmore's Who's Who Date: Mon, 02 Nov 2009 12:03:39 -0500 MIME-Version: 1.0 List-Unsubscribe: Content-type: multipart/alternative; boundary="----------030700010607050800090606"; X-Barracuda-Connect: mail2.globalnetstore.com[208.53.152.59] X-Barracuda-Start-Time: 1257181420 Message-Id: <20091102170339.4961314CF4A8@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.4463 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.32 X-Barracuda-Spam-Status: No, SCORE=1.32 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_IMAGE_ONLY_32, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13541 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.32 HTML_IMAGE_ONLY_32 BODY: HTML: images with 2800-3200 bytes of words 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean ------------030700010607050800090606 Content-type: text/plain Jakob, It is my pleasure to inform you that on September 24th, 2009 your information was reviewed and accepted for inclusion in the 2009/2010 edition of our registry. Strathmore's Whos Who each year, recognizes and selects key executives, professionals and organizations in all disciplines and industries for outstanding business and professional achievements. This recognition is shared by those who have reached a distinguished level of success in their chosen profession. Please take a moment to complete the invitation by clicking on the link below. We ask that you complete it carefully, as it will be reviewed by our editorial department. http://www.formdesk.com/pgn6/STR ** Please complete the online link by October 10th. Strathmore's Whos Who is pleased to inform you that there are no fees or dues to be included in the publication. On behalf of the CEO and our esteemed staff, we wish you continued success. Sincerely, J. Edward Simmons Vice President, Research Division Strathmore's Whos Who 26 Bond St. Westbury NY 11590 Thanks ------------030700010607050800090606 Content-Type: text/html

Jakob,

It is my pleasure to inform you that on September 24th, 2009 your information was reviewed and accepted for inclusion in the 2009/2010 edition of our registry.

Strathmore's Whos Who each year, recognizes and selects key executives, professionals and organizations in all disciplines and industries for outstanding business and professional achievements.

This recognition is shared by those who have reached a distinguished level of success in their chosen profession.

Please take a moment to complete the invitation by clicking on the link below. We ask that you complete it carefully, as it will be reviewed by our editorial department.

http://www.formdesk.com/pgn6/STR

** Please complete the online link by October 10th.

Strathmore's Whos Who is pleased to inform you that there are no fees or dues to be included in the publication.

On behalf of the CEO and our esteemed staff, we wish you continued success.

Sincerely,

J. Edward Simmons
Vice President, Research Division

Strathmore's Whos Who
26 Bond St.
Westbury NY 11590

Thanks

We only support ethical email marketing. To remove yourself from future mailings, please visit here to use our automated removal system. You will be removed from our mailing database within seven (7) days. 10510
Thanks

------------030700010607050800090606-- From eflorac@intellique.com Mon Nov 2 11:52:42 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BRBL autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2HqgKv078986 for ; Mon, 2 Nov 2009 11:52:42 -0600 X-ASG-Debug-ID: 1257184370-4d3102e80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 26971180B3D5 for ; Mon, 2 Nov 2009 09:52:53 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by cuda.sgi.com with ESMTP id GvamCvdpdq1ECvU7 for ; Mon, 02 Nov 2009 09:52:53 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 15A884B00DD; Mon, 2 Nov 2009 18:52:47 +0100 (CET) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by smtp2-g21.free.fr (Postfix) with ESMTP id E6A2F4B0056; Mon, 2 Nov 2009 18:52:44 +0100 (CET) Date: Mon, 2 Nov 2009 18:52:49 +0100 From: Emmanuel Florac To: Michael Monnerie Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files Message-ID: <20091102185249.0da8e388@harpe.intellique.com> In-Reply-To: <200911021205.28006@zmi.at> References: <4AEC2CF4.8040703@aol.com> <4AEC4BAA.20606@aol.com> <20091031174836.3fc9505b@galadriel.home> <200911021205.28006@zmi.at> Organization: Intellique X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp2-g21.free.fr[212.27.42.2] X-Barracuda-Start-Time: 1257184376 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13546 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Mon, 2 Nov 2009 12:05:27 +0100 Michael Monnerie =E9crivait: > I believe for a 15 drive RAID-6, where 2 disks are used for > redundancy, the correct mkfs would be: > mkfs -t xfs -d su=3D65536,sw=3D13 /dev/sdXX Yes you're right, I replied a bit too quickly :) > Another thing to try is if it would help to turn disk cache writes > *on*, despite all warnings if the FAQ.=20 The 3Ware is so slow it's almost unusable without write cache. I bet he already uses it anyway. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Intellique ------------------------------------------------------------------------ From aelder@sgi.com Mon Nov 2 12:46:23 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2IkNep082790 for ; Mon, 2 Nov 2009 12:46:23 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay3.corp.sgi.com (Postfix) with ESMTP id F3555AC003; Mon, 2 Nov 2009 10:46:33 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfstests: add another quotaoff testcase to 220 Date: Mon, 2 Nov 2009 12:46:33 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE56@cf--amer001e--3.americas.sgi.com> In-Reply-To: <20091030093155.GA9329@infradead.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] xfstests: add another quotaoff testcase to 220 Thread-Index: AcpZR6hwObLW6KXRQo+/xSOHs3aRgwCpNifA From: "Alex Elder" To: "Christoph Hellwig" Cc: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > Add the quotafile space remove regression test from Ryota Yamauchi to > testcase 220. Looks good. This tests the actual problem reported by Ryota Yamauchi. > Signed-off-by: Christoph Hellwig Reviewed-by: Alex Elder > Index: xfstests-dev/220 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- xfstests-dev.orig/220 2009-10-30 09:16:52.000000000 +0000 > +++ xfstests-dev/220 2009-10-30 09:29:19.000000000 +0000 > @@ -1,10 +1,10 @@ > #! /bin/sh > # FS QA Test No. 220 > # > -# Test that turning quotas off on a mounted filesystem doesn't crash > -# the system. > +# Test quota off handling. > # > -# Based on a bug report from Utako Kusaka . > +# Based on bug reports from Utako Kusaka and > +# Ryota Yamauchi . > # > = #----------------------------------------------------------------------- > # Copyright (c) 2009 Christoph Hellwig. All Rights Reserved. > @@ -67,5 +67,19 @@ xfs_quota -x -c off $SCRATCH_DEV > # and unmount (this used to crash) > umount $SCRATCH_DEV >=20 > + > +# create scratch filesystem > +_scratch_mkfs_xfs >/dev/null 2>&1 > + > +# mount with quotas enabled > +_scratch_mount -o uquota > + > +# turn off quota and remove space allocated to the quota files > +# (this used to give wrong ENOSYS returns in 2.6.31) > +xfs_quota -x -c off -c remove $SCRATCH_DEV > + > +# and unmount again > +umount $SCRATCH_DEV > + > status=3D0 > exit $status >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From aelder@sgi.com Mon Nov 2 13:00:56 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2J0uHS084001 for ; Mon, 2 Nov 2009 13:00:56 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay3.corp.sgi.com (Postfix) with ESMTP id 79A70AC004; Mon, 2 Nov 2009 11:01:06 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfststests 220: test for prealloc/delalloc/reserved spacerecapture Date: Mon, 2 Nov 2009 13:01:05 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE58@cf--amer001e--3.americas.sgi.com> In-Reply-To: <4AC4FC13.3050505@redhat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] xfststests 220: test for prealloc/delalloc/reserved spacerecapture Thread-Index: AcpCysh2YvuJTV0uSryK+4+GQVJ71QZI7fcQ From: "Alex Elder" To: "Eric Sandeen" Cc: "ext4 development" , "xfs-oss" X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Eric Sandeen wrote: > Test writing and removing a file in a loop; filesize is 64m, > filesystem size is 256m. Loop 16 times each for buffered and > direct. >=20 > ext4 hits enospc after a couple loops. >=20 > Signed-off-by: Eric Sandeen > --- Dumb nit mentioned below, but otherwise looks good. Also note that you'll need to use a different test number now--like 221. Reviewed-by: Alex Elder > (note this has the sized mkfs infra from the previous patch this week > since that patch needed more work w.r.t. modifying existing tests) >=20 > diff --git a/common.rc b/common.rc > index 761170d..8d0cd4e 100644 > --- a/common.rc > +++ b/common.rc > @@ -237,6 +237,27 @@ _scratch_mkfs_options() > echo $SCRATCH_OPTIONS $MKFS_OPTIONS $* $SCRATCH_DEV > } >=20 > +# arg 1 is size in bytes, arg 2 is (optional) blocksize > +_scratch_mkfs_sized() > +{ > + fssz=3D$1 > + bsz=3D$2 > + [ -z "$bsz" ] && bsz=3D4096 > + let blocks=3D$fssz/$bsz > + > + case $FSTYP in > + xfs) > + _scratch_mkfs_xfs -d size=3D$fssz -b size=3D$bsz 2>&1 = >>$here/$seq.full > + ;; > + ext2|ext3|ext4) > + /sbin/mkfs -t $FSTYP -- $MKFS_OPTIONS -b $bsz $SCRATCH_DEV = $blocks=20 > 2>&1>>$here/$seq.full + ;; > + *) > + _notrun "Filesystem $FSTYP not supported in _scratch_mkfs_sized" > + ;; > + esac > +} > + > _scratch_mkfs_xfs() > { > # extra mkfs options can be added by tests >=20 > diff --git a/220 b/220 > new file mode 100755 > index 0000000..55982b7 > --- /dev/null > +++ b/220 > @@ -0,0 +1,76 @@ > +#! /bin/sh > +# FS QA Test No. 220 > +# > +# Test for prealloc space leaks by rewriting the same file in a loop > +# > = +#-----------------------------------------------------------------------= > +# Copyright (c) 2009 Eric Sandeen. All Rights Reserved. > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation. > +# > +# This program is distributed in the hope that it would be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write the Free Software = Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > +# > = +#-----------------------------------------------------------------------= > +# > +# creator > +owner=3Dsandeen@sandeen.net > + > +seq=3D`basename $0` > +echo "QA output created by $seq" > + > +here=3D`pwd` > +tmp=3D/tmp/$$ > +status=3D1 # failure is the default! > +trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15 > + > +# get standard environment, filters and checks > +. ./common.rc > + > +# real QA test starts here > +_supported_fs generic > +_supported_os Linux IRIX > +_require_scratch > + > +# real QA test starts here So which is it, here or above that the "real QA test starts"? > +rm -f $seq.full > + > +umount $SCRATCH_DEV 2>/dev/null > +let fssize=3D256*1024*1024 > +echo "--> mkfs 256m filesystem" > +_scratch_mkfs_sized $fssize >> $seq.full 2>&1 > +_scratch_mount > + > +loops=3D16 > + > +echo "--> $loops buffered 64m writes in a loop" > +for I in `seq 1 $loops`; do > + echo -n "$I " > + xfs_io -F -f -c 'pwrite 0 64m' $SCRATCH_MNT/test >> $seq.full > + rm -f $SCRATCH_MNT/test > +done > + > +echo > +umount $SCRATCH_DEV > +_scratch_mount > + > +echo "--> $loops direct 64m writes in a loop" > +for I in `seq 1 $loops`; do > + echo -n "$I " > + xfs_io -F -f -d -c 'pwrite 0 64m' $SCRATCH_MNT/test >> $seq.full > + rm -f $SCRATCH_MNT/test > +done > + > +echo > +umount $SCRATCH_DEV > + > +status=3D0 > +exit > diff --git a/220.out b/220.out > new file mode 100644 > index 0000000..497a585 > --- /dev/null > +++ b/220.out > @@ -0,0 +1,6 @@ > +QA output created by 220 > +--> mkfs 256m filesystem > +--> 16 buffered 64m writes in a loop > +1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > +--> 16 direct 64m writes in a loop > +1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > diff --git a/group b/group > index 7cea01d..9b8a401 100644 > --- a/group > +++ b/group > @@ -329,3 +329,4 @@ prealloc > 217 log metadata auto > 218 auto fsr quick > 219 auto quota quick > +220 enospc auto quick >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@redhat.com Mon Nov 2 13:15:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2JFH2x085088 for ; Mon, 2 Nov 2009 13:15:17 -0600 X-ASG-Debug-ID: 1257189330-4b1f01180000-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 B8F51180BD65; Mon, 2 Nov 2009 11:15:30 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id AlGlSVqshnpxS6y3; Mon, 02 Nov 2009 11:15:30 -0800 (PST) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nA2JFTmg031817; Mon, 2 Nov 2009 14:15:29 -0500 Received: from liberator.sandeen.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nA2JFP9l031898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 14:15:28 -0500 Message-ID: <4AEF2FCD.4090707@redhat.com> Date: Mon, 02 Nov 2009 13:15:25 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alex Elder CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] xfststests 220: test for prealloc/delalloc/reserved spacerecapture Subject: Re: [PATCH] xfststests 220: test for prealloc/delalloc/reserved spacerecapture References: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE58@cf--amer001e--3.americas.sgi.com> In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE58@cf--amer001e--3.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1257189330 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13550 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Alex Elder wrote: > Eric Sandeen wrote: >> Test writing and removing a file in a loop; filesize is 64m, >> filesystem size is 256m. Loop 16 times each for buffered and >> direct. >> >> ext4 hits enospc after a couple loops. >> >> Signed-off-by: Eric Sandeen >> --- > > > Dumb nit mentioned below, but otherwise looks good. > Also note that you'll need to use a different test > number now--like 221. > > Reviewed-by: Alex Elder > > ... >> +# real QA test starts here >> +_supported_fs generic >> +_supported_os Linux IRIX >> +_require_scratch >> + >> +# real QA test starts here > > So which is it, here or above that the "real QA test starts"? It depends on how you measure the starting point, and in fact by measuring, you may affect the outcome of that measurement ... it could be both at the same time! -Eric Heisenberg From william@netproteus.net Mon Nov 2 14:02:11 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2K2A6E088661 for ; Mon, 2 Nov 2009 14:02:11 -0600 X-ASG-Debug-ID: 1257192141-0dbf019f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ew0-f221.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7072C14D0413 for ; Mon, 2 Nov 2009 12:02:22 -0800 (PST) Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by cuda.sgi.com with ESMTP id l2h0A7v1kGtcyPVm for ; Mon, 02 Nov 2009 12:02:22 -0800 (PST) Received: by ewy21 with SMTP id 21so5057057ewy.8 for ; Mon, 02 Nov 2009 12:02:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.90.9 with SMTP id d9mr65224wef.201.1257192141040; Mon, 02 Nov 2009 12:02:21 -0800 (PST) X-Originating-IP: [83.166.71.4] Date: Mon, 2 Nov 2009 20:02:20 +0000 Message-ID: <7a12b48b0911021202l126e10a1pbc281f6922380f48@mail.gmail.com> X-ASG-Orig-Subj: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. Subject: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. From: William Lewis To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=0016e6da7de3fb2da1047768daae X-Barracuda-Connect: mail-ew0-f221.google.com[209.85.219.221] X-Barracuda-Start-Time: 1257192143 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13553 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0016e6da7de3fb2da1047768daae Content-Type: text/plain; charset=ISO-8859-1 Hi, I am in the process of setting up an XFS file system on underlying hardware consisting of a 3ware 9550SXU (+ battery backup module) and 4 x Seagate ST31500341AS 1.5TB hard drives in Raid 5 configuration. Reading your FAQ at http://xfs.org/index.php/XFS_FAQ I understand that it is advisable to mount the file system with nobarrier to improve performance. However going on to read about recommended settings for write cache, the advice for 3ware hardware doesn't seem to account for the fact that there are 2 levels of write cache in play, that in the 3ware card itself protected by the battery and the write cache of the disks themselves, which as far as I can understand is also protected by the battery backup (in the correct storage modes - balanced/protection) because the 3ware card uses write journaling to keep track of pending write operations in the disks' cache. Therefore unless I am misunderstanding something the most benefit is to be gained by mounting with nobarrier and having the write cache turned on? One thing I am not clear about is if nobarrier interacts with the page cache at all and if the lack of barrier leaves you with a situation in which pending writes can be lost from main memory on power failure? Thanks in advance for any clarification you can provide. Regards Will Lewis --0016e6da7de3fb2da1047768daae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am in the process of setting up an XFS file system on underlyi= ng hardware consisting of a 3ware 9550SXU (+ battery backup module) and 4 x= Seagate ST31500341AS 1.5TB hard drives in Raid 5 configuration.

Reading your FAQ at http://xfs= .org/index.php/XFS_FAQ I understand that it is advisable to mount the f= ile system with nobarrier to improve performance. However going on to read = about recommended settings for write cache, the advice for 3ware hardware d= oesn't seem to account for the fact that there are 2 levels of write ca= che in play, that in the 3ware card itself protected by the battery and the= write cache of the disks themselves, which as far as I can understand is a= lso protected by the battery backup (in the correct storage modes - balance= d/protection) because the 3ware card uses write journaling to keep track of= pending write operations in the disks' cache. Therefore unless I am mi= sunderstanding something the most benefit is to be gained by mounting with = nobarrier and having the write cache turned on?

One thing I am not clear about is if nobarrier interacts with the page = cache at all and if the lack of barrier leaves you with a situation in whic= h pending writes can be lost from main memory on power failure?

Thanks in advance for any clarification you can provide.

Regards
=
Will Lewis
--0016e6da7de3fb2da1047768daae-- From aelder@sgi.com Mon Nov 2 14:33:52 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2KXpGd091489 for ; Mon, 2 Nov 2009 14:33:52 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay3.corp.sgi.com (Postfix) with ESMTP id 72B17AC008; Mon, 2 Nov 2009 12:34:02 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfs: I/O completion handlers must use NOFS allocations Date: Mon, 2 Nov 2009 14:34:01 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5B@cf--amer001e--3.americas.sgi.com> In-Reply-To: <20091019040003.GA21115@infradead.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] xfs: I/O completion handlers must use NOFS allocations Thread-Index: AcpQchCAk8Ba56CpQRWbxrqJPuWXawLiHbSw From: "Alex Elder" To: "Christoph Hellwig" Cc: "Thomas Neumann" , X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > When complention I/O requests we must not allow the memory allocator = to > recurse into the filesystem, as we might deadlock on waiting for the > I/O completion otherwise. The only thing currently allocting normal > GFP_KERNEL memory is the allocation of the transaction structure for = the > unwritten extent conversion. Add a memflags argument to = _xfs_trans_alloc > to allow controlling the allocator behaviour. >=20 > Signed-off-by: Christoph Hellwig > Reported-by: Thomas Neumann > Tested-by: Thomas Neumann This looks good. It's kind of too bad the GFP_ flag argument had to be added, but I can't think of a cleaner way than the way you did it. I have one minor suggestion on wording used in a comment, but the code looks correct to me. I verified that--as you say--the only place we're doing an allocation in an I/O completion handler (i.e., a function called via io_end->io_work->func) is in xfs_iomap_write_unwritten(), so this fix should cover the only case. Sorry it took so long to get to this. Reviewed-by: Alex Elder > Index: linux-2.6/fs/xfs/xfs_fsops.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/fs/xfs/xfs_fsops.c 2009-10-16 23:08:25.170027882 = +0200 > +++ linux-2.6/fs/xfs/xfs_fsops.c 2009-10-16 23:09:22.904256700 +0200 > @@ -611,7 +611,7 @@ xfs_fs_log_dummy( > xfs_inode_t *ip; > int error; >=20 > - tp =3D _xfs_trans_alloc(mp, XFS_TRANS_DUMMY1); > + tp =3D _xfs_trans_alloc(mp, XFS_TRANS_DUMMY1, KM_SLEEP); > error =3D xfs_trans_reserve(tp, 0, XFS_ICHANGE_LOG_RES(mp), 0, 0, = 0); > if (error) { > xfs_trans_cancel(tp, 0); > Index: linux-2.6/fs/xfs/xfs_iomap.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/fs/xfs/xfs_iomap.c 2009-10-16 23:10:14.342278346 = +0200 > +++ linux-2.6/fs/xfs/xfs_iomap.c 2009-10-16 23:12:08.148004392 +0200 > @@ -860,8 +860,15 @@ xfs_iomap_write_unwritten( > * set up a transaction to convert the range of extents > * from unwritten to real. Do allocations in a loop until > * we have covered the range passed in. > + * > + * Note that we opencoding the transaction allocation here > + * to pass KM_NOFS - we can't risk to recurse back into How about, "we can't risk recursing back into" > + * the filesystem here as we might be asked to write out > + * the same inode that we complete here and might deadlock > + * on the iolock. > */ > - tp =3D xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE); > + xfs_wait_for_freeze(mp, SB_FREEZE_TRANS); > + tp =3D _xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE, KM_NOFS); > tp->t_flags |=3D XFS_TRANS_RESERVE; > error =3D xfs_trans_reserve(tp, resblks, > XFS_WRITE_LOG_RES(mp), 0, > Index: linux-2.6/fs/xfs/xfs_mount.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/fs/xfs/xfs_mount.c 2009-10-16 23:08:25.147024815 = +0200 > +++ linux-2.6/fs/xfs/xfs_mount.c 2009-10-16 23:09:25.127005437 +0200 > @@ -1471,7 +1471,7 @@ xfs_log_sbcount( > if (!xfs_sb_version_haslazysbcount(&mp->m_sb)) > return 0; >=20 > - tp =3D _xfs_trans_alloc(mp, XFS_TRANS_SB_COUNT); > + tp =3D _xfs_trans_alloc(mp, XFS_TRANS_SB_COUNT, KM_SLEEP); > error =3D xfs_trans_reserve(tp, 0, mp->m_sb.sb_sectsize + 128, 0, 0, > XFS_DEFAULT_LOG_COUNT); > if (error) { > Index: linux-2.6/fs/xfs/xfs_trans.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/fs/xfs/xfs_trans.c 2009-10-16 23:08:25.117003816 = +0200 > +++ linux-2.6/fs/xfs/xfs_trans.c 2009-10-16 23:08:58.202005942 +0200 > @@ -236,19 +236,20 @@ xfs_trans_alloc( > uint type) > { > xfs_wait_for_freeze(mp, SB_FREEZE_TRANS); > - return _xfs_trans_alloc(mp, type); > + return _xfs_trans_alloc(mp, type, KM_SLEEP); > } >=20 > xfs_trans_t * > _xfs_trans_alloc( > xfs_mount_t *mp, > - uint type) > + uint type, > + uint memflags) > { > xfs_trans_t *tp; >=20 > atomic_inc(&mp->m_active_trans); >=20 > - tp =3D kmem_zone_zalloc(xfs_trans_zone, KM_SLEEP); > + tp =3D kmem_zone_zalloc(xfs_trans_zone, memflags); > tp->t_magic =3D XFS_TRANS_MAGIC; > tp->t_type =3D type; > tp->t_mountp =3D mp; > Index: linux-2.6/fs/xfs/xfs_trans.h > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/fs/xfs/xfs_trans.h 2009-10-16 23:08:25.127003692 = +0200 > +++ linux-2.6/fs/xfs/xfs_trans.h 2009-10-16 23:09:04.726256000 +0200 > @@ -924,7 +924,7 @@ typedef struct xfs_trans { > * XFS transaction mechanism exported interfaces. > */ > xfs_trans_t *xfs_trans_alloc(struct xfs_mount *, uint); > -xfs_trans_t *_xfs_trans_alloc(struct xfs_mount *, uint); > +xfs_trans_t *_xfs_trans_alloc(struct xfs_mount *, uint, uint); > xfs_trans_t *xfs_trans_dup(xfs_trans_t *); > int xfs_trans_reserve(xfs_trans_t *, uint, uint, uint, > uint, uint); >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From aelder@sgi.com Mon Nov 2 15:10:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2LAM0c094004 for ; Mon, 2 Nov 2009 15:10:22 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay1.corp.sgi.com (Postfix) with ESMTP id 69E128F8050; Mon, 2 Nov 2009 13:10:33 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfs: fix mmap_sem vs iolock lock order inversion inxfs_free_eofblocks Date: Mon, 2 Nov 2009 15:10:33 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5C@cf--amer001e--3.americas.sgi.com> In-Reply-To: <20091019040346.GB21115@infradead.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] xfs: fix mmap_sem vs iolock lock order inversion inxfs_free_eofblocks Thread-Index: AcpQcg8MZ3qG2Av4SZSGwI82xVJoXQLjSOzw From: "Alex Elder" To: "Christoph Hellwig" Cc: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > When xfs_free_eofblocks is called from ->release the VM might already > hold the mmap_sem, but in the write path we take the iolock before > taking the mmap_sem in the generic write code. >=20 > Switch xfs_free_eofblocks to only trylock the iolock if called from = ->release > and skip trimming the prellocated blocks in that case. We'll still = free > them later on the final iput. >=20 > Signed-off-by: Christoph Hellwig I have a minor suggestion below, but it looks correct to me. I tried to get a better idea of what the conditions were where mmap_sem would be held by VM when ->release gets called, but didn't get to the bottom of that. If it is easily characterized you could mention it in comments. Reviewed-by: Alex Elder > Index: xfs/fs/xfs/xfs_rw.h > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- xfs.orig/fs/xfs/xfs_rw.h 2009-10-14 17:30:02.396028076 +0200 > +++ xfs/fs/xfs/xfs_rw.h 2009-10-14 17:30:20.472287472 +0200 > @@ -37,13 +37,6 @@ xfs_fsb_to_db(struct xfs_inode *ip, xfs_ > } >=20 > /* > - * Flags for xfs_free_eofblocks > - */ > -#define XFS_FREE_EOF_LOCK (1<<0) > -#define XFS_FREE_EOF_NOLOCK (1<<1) > - > - > -/* > * helper function to extract extent size hint from inode > */ > STATIC_INLINE xfs_extlen_t > Index: xfs/fs/xfs/xfs_vnodeops.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- xfs.orig/fs/xfs/xfs_vnodeops.c 2009-10-14 17:30:13.363024201 +0200 > +++ xfs/fs/xfs/xfs_vnodeops.c 2009-10-14 17:35:39.314256388 +0200 > @@ -709,6 +709,11 @@ xfs_fsync( > } >=20 > /* > + * Flags for xfs_free_eofblocks > + */ > +#define XFS_FREE_EOF_TRYLOCK (1<<0) This is really a Boolean in the place it's used, rather than a flags mask. Unless you have plans to add other flags, maybe just don't bother defining this, and pass a zero/non-zero for a renamed argument to xfs_free_eofblocks(). (I mention this again below, in that context.) > +/* > * This is called by xfs_inactive to free any blocks beyond eof > * when the link count isn't zero and by xfs_dm_punch_hole() when > * punching a hole to EOF. > @@ -726,7 +731,6 @@ xfs_free_eofblocks( > xfs_filblks_t map_len; > int nimaps; > xfs_bmbt_irec_t imap; > - int use_iolock =3D (flags & XFS_FREE_EOF_LOCK); >=20 > /* > * Figure out if there are any blocks beyond the end > @@ -768,14 +772,19 @@ xfs_free_eofblocks( > * cache and we can't > * do that within a transaction. > */ > - if (use_iolock) > + if (flags & XFS_FREE_EOF_TRYLOCK) { If you rename "flag" to "skip_ok" (or maybe "try_lock": if (skip_ok && ! xfs_ilock_nowait(...)) { xfs_trans_cancel(); return 0; } else xfs_ilock(...); if (try_lock) > + if (!xfs_ilock_nowait(ip, XFS_IOLOCK_EXCL)) { > + xfs_trans_cancel(tp, 0); > + return 0; > + } > + } else { > xfs_ilock(ip, XFS_IOLOCK_EXCL); > + } > error =3D xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, > ip->i_size); > if (error) { > xfs_trans_cancel(tp, 0); > - if (use_iolock) > - xfs_iunlock(ip, XFS_IOLOCK_EXCL); > + xfs_iunlock(ip, XFS_IOLOCK_EXCL); > return error; > } >=20 > @@ -812,8 +821,7 @@ xfs_free_eofblocks( > error =3D xfs_trans_commit(tp, > XFS_TRANS_RELEASE_LOG_RES); > } > - xfs_iunlock(ip, (use_iolock ? (XFS_IOLOCK_EXCL|XFS_ILOCK_EXCL) > - : XFS_ILOCK_EXCL)); > + xfs_iunlock(ip, XFS_IOLOCK_EXCL|XFS_ILOCK_EXCL); > } > return error; > } > @@ -1113,7 +1121,17 @@ xfs_release( > (ip->i_df.if_flags & XFS_IFEXTENTS)) && > (!(ip->i_d.di_flags & > (XFS_DIFLAG_PREALLOC | XFS_DIFLAG_APPEND)))) { > - error =3D xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); > + > + /* > + * If we can't get the iolock just skip truncating > + * the blocks past EOF because we could deadlock > + * with the mmap_sem otherwise. We'll get another > + * chance to drop them once the last reference to > + * the inode is dropped, so we'll never leak blocks > + * permanently. > + */ > + error =3D xfs_free_eofblocks(mp, ip, > + XFS_FREE_EOF_TRYLOCK); > if (error) > return error; > } > @@ -1184,7 +1202,7 @@ xfs_inactive( > (!(ip->i_d.di_flags & > (XFS_DIFLAG_PREALLOC | XFS_DIFLAG_APPEND)) || > (ip->i_delayed_blks !=3D 0)))) { > - error =3D xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); > + error =3D xfs_free_eofblocks(mp, ip, 0); > if (error) > return VN_INACTIVE_CACHE; > } >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From jpiszcz@lucidpixels.com Mon Nov 2 15:29:00 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2LSxZk095032 for ; Mon, 2 Nov 2009 15:28:59 -0600 X-ASG-Debug-ID: 1257197352-4c9703d60000-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 10D4B1B398CA for ; Mon, 2 Nov 2009 13:29:12 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id CWvhHsoB5gVkyujH for ; Mon, 02 Nov 2009 13:29:12 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 199C6805324F; Mon, 2 Nov 2009 16:29:12 -0500 (EST) Date: Mon, 2 Nov 2009 16:29:12 -0500 (EST) From: Justin Piszcz To: William Lewis cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. Subject: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. In-Reply-To: <7a12b48b0911021202l126e10a1pbc281f6922380f48@mail.gmail.com> Message-ID: References: <7a12b48b0911021202l126e10a1pbc281f6922380f48@mail.gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) 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: 1257197353 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13560 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, 2 Nov 2009, William Lewis wrote: > Hi, > > I am in the process of setting up an XFS file system on underlying hardware > consisting of a 3ware 9550SXU (+ battery backup module) and 4 x Seagate > ST31500341AS 1.5TB hard drives in Raid 5 configuration. > > Reading your FAQ at http://xfs.org/index.php/XFS_FAQ I understand that it is > advisable to mount the file system with nobarrier to improve performance. > However going on to read about recommended settings for write cache, the > advice for 3ware hardware doesn't seem to account for the fact that there > are 2 levels of write cache in play, that in the 3ware card itself protected > by the battery and the write cache of the disks themselves, which as far as > I can understand is also protected by the battery backup (in the correct > storage modes - balanced/protection) because the 3ware card uses write > journaling to keep track of pending write operations in the disks' cache. > Therefore unless I am misunderstanding something the most benefit is to be > gained by mounting with nobarrier and having the write cache turned on? > > One thing I am not clear about is if nobarrier interacts with the page cache > at all and if the lack of barrier leaves you with a situation in which > pending writes can be lost from main memory on power failure? > > Thanks in advance for any clarification you can provide. > > Regards > > Will Lewis > I am also curious, I have a 16 drive RAID-6 configuration on a 9650SE-16ML and using -o nobarrier or mounting normal the speed/benchmarks seemed to be the same. Either barriers are not enabled by default for 3ware RAID arrays or they make no difference in performance? Justin. From sandeen@sandeen.net Mon Nov 2 15:31:21 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2LVK7j095166 for ; Mon, 2 Nov 2009 15:31:20 -0600 X-ASG-Debug-ID: 1257197493-686303b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 190F25653F for ; Mon, 2 Nov 2009 13:31:33 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 7feg9qW21MG2aXPs for ; Mon, 02 Nov 2009 13:31:33 -0800 (PST) Received: from liberator.sandeen.net (sandeen.net [209.173.210.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 52E79AAE3B1; Mon, 2 Nov 2009 15:31:31 -0600 (CST) Message-ID: <4AEF4FB2.1050504@sandeen.net> Date: Mon, 02 Nov 2009 15:31:30 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: William Lewis CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. Subject: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. References: <7a12b48b0911021202l126e10a1pbc281f6922380f48@mail.gmail.com> In-Reply-To: <7a12b48b0911021202l126e10a1pbc281f6922380f48@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1257197494 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13560 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean William Lewis wrote: > Hi, > > I am in the process of setting up an XFS file system on underlying > hardware consisting of a 3ware 9550SXU (+ battery backup module) and 4 x > Seagate ST31500341AS 1.5TB hard drives in Raid 5 configuration. > > Reading your FAQ at http://xfs.org/index.php/XFS_FAQ I understand that > it is advisable to mount the file system with nobarrier to improve > performance. However going on to read about recommended settings for > write cache, the advice for 3ware hardware doesn't seem to account for > the fact that there are 2 levels of write cache in play, that in the > 3ware card itself protected by the battery and the write cache of the > disks themselves, which as far as I can understand is also protected by > the battery backup (in the correct storage modes - balanced/protection) > because the 3ware card uses write journaling to keep track of pending > write operations in the disks' cache. Therefore unless I am > misunderstanding something the most benefit is to be gained by mounting > with nobarrier and having the write cache turned on? If the write caches won't go away - or will be fully/gracefully destaged before they do, then nobarrier should be safe. > One thing I am not clear about is if nobarrier interacts with the page > cache at all and if the lack of barrier leaves you with a situation in > which pending writes can be lost from main memory on power failure? nobarrier has no interaction with the OS page cache; all the "barrier" option (the default) does is enforce ordering for journal IO*, and in practice it does this by flushing the cache at points in time. -Eric *well, I think it flushes the drive cache on fsync, too, for data integrity (vs. the metadata integrity for the journal IO ordering) > Thanks in advance for any clarification you can provide. > > Regards > > Will Lewis > > > ------------------------------------------------------------------------ > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Mon Nov 2 15:34:23 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2LYMEU095343 for ; Mon, 2 Nov 2009 15:34:23 -0600 X-ASG-Debug-ID: 1257197675-129300d00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1242B14D0ADB for ; Mon, 2 Nov 2009 13:34:35 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id Yb6o2wt9qDo2Evag for ; Mon, 02 Nov 2009 13:34:35 -0800 (PST) Received: from liberator.sandeen.net (sandeen.net [209.173.210.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id CD397AAE3B1; Mon, 2 Nov 2009 15:34:34 -0600 (CST) Message-ID: <4AEF506A.8060803@sandeen.net> Date: Mon, 02 Nov 2009 15:34:34 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "AndrewL733@aol.com" CC: Emmanuel Florac , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files References: <4AEC2CF4.8040703@aol.com> <20091031151825.46210b6a@galadriel.home> <4AEC4BAA.20606@aol.com> In-Reply-To: <4AEC4BAA.20606@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1257197676 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13559 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean AndrewL733@aol.com wrote: > >> Maybe you should try mounting the XFS filesystem with these options : >> nobarrier,noatime >> >> > Thanks. Already doing that -- 3ware controller does not support > barriers, so that's automatically ruled out (you see a message in the > syslog when mounting the filesystem that barriers will not be used). > Already mounting with "noatime". Also have been trying "filestreams". Filestreams is really only useful if you have multiple threads writing in this manner - for example 2 different movie streams. Normally an allocation group is chosen for all new files in a directory, so if you have 2 streams to 2 directories you are writing to 2 ag's ... all is good until those ags get full and things spill over. At that point you may wind up interleaving those files from both streams in a 3rd ag. the filestreams option more or less locks out the new ag from other streams, so that stuff stays segregated. If this is your situation (multiple streams, each to their own directory), then filestreams may help. I think for a single stream of files, for a single video source, it won't matter. -Eric From jpiszcz@lucidpixels.com Mon Nov 2 15:45:58 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2Ljwt1095854 for ; Mon, 2 Nov 2009 15:45:58 -0600 X-ASG-Debug-ID: 1257198370-5abd038a0000-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 8FCF41D8BF43 for ; Mon, 2 Nov 2009 13:46:10 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id WEj9GQz1DvfjSksc for ; Mon, 02 Nov 2009 13:46:10 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 096A7805324C; Mon, 2 Nov 2009 16:46:10 -0500 (EST) Date: Mon, 2 Nov 2009 16:46:10 -0500 (EST) From: Justin Piszcz To: Dave Chinner cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz X-ASG-Orig-Subj: Re: 2.6.31+2.6.31.4: XFS - All I/O locks up to D-state after 24-48 hours (sysrq-t+w available) Subject: Re: 2.6.31+2.6.31.4: XFS - All I/O locks up to D-state after 24-48 hours (sysrq-t+w available) In-Reply-To: Message-ID: References: <20091019030456.GS9464@discord.disaster> <20091020003358.GW9464@discord.disaster> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) 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: 1257198371 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13560 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, 26 Oct 2009, Justin Piszcz wrote: > > > On Thu, 22 Oct 2009, Justin Piszcz wrote: > >> >> Any other ideas? >> >> Currently stuck on 2.6.30.9.. (no issues, no lockups)-- Box normally has no >> load at all either.. Has anyone else reported similar problems? >> >> Justin. >> > > -- > > Currently running 2.6.31-rc1 for 2 days now, no crashes, will go to -rc2 > later today and wait another 48 hours. > > Justin. > > Kernel report: 2.6.31-rc1: no crash - uptime 2+ days 2.6.31-rc2: no crash - uptime 2+ days 2.6.31-rc3: no crash - uptime 2+ days 2.6.31-rc4: no crash but network kept dropping out 2.6.31-rc5: cannot test, service owner needs host available 2.6.31-rc6: cannot test, service owner needs host available 2.6.31-rc7: cannot test, service owner needs host available 2.6.31-rc8: cannot test, service owner needs host available 2.6.31-rc9: cannot test, service owner needs host available 2.6.31.x: locks up D-state It would be somewhere between -rc4 and 2.6.31.x. Justin. From AndrewL733@aol.com Mon Nov 2 15:50:39 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2LodUa096087 for ; Mon, 2 Nov 2009 15:50:39 -0600 X-ASG-Debug-ID: 1257198652-7aae00cf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mxout-08.mxes.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D5A95566D0 for ; Mon, 2 Nov 2009 13:50:52 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by cuda.sgi.com with ESMTP id m53XAiL6GFLuG3FF for ; Mon, 02 Nov 2009 13:50:52 -0800 (PST) Received: from [192.168.1.144] (unknown [209.94.131.238]) by smtp.mxes.net (Postfix) with ESMTPA id 567A7509D9; Mon, 2 Nov 2009 16:50:49 -0500 (EST) Message-ID: <4AEF5438.5050801@aol.com> Date: Mon, 02 Nov 2009 16:50:48 -0500 From: "AndrewL733@aol.com" User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Emmanuel Florac CC: Michael Monnerie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files References: <4AEC2CF4.8040703@aol.com> <4AEC4BAA.20606@aol.com> <20091031174836.3fc9505b@galadriel.home> <200911021205.28006@zmi.at> <20091102185249.0da8e388@harpe.intellique.com> In-Reply-To: <20091102185249.0da8e388@harpe.intellique.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mxout-08.mxes.net[216.86.168.183] X-Barracuda-Start-Time: 1257198652 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13561 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean >> I believe for a 15 drive RAID-6, where 2 disks are used forredundancy, the correct mkfs would be: >> mkfs -t xfs -d su=65536,sw=13 /dev/sdXX >> > > Yes you're right, I replied a bit too quickly :) > > > >> Another thing to try is if it would help to turn disk cache writes >> *on*, despite all warnings if the FAQ. >> Thank you for your suggestions. Yes I have write caching enabled. And I have StorSave set to "Performance". And I have a UPS on the system at all times! The information about barriers was useful. In years past I was running much older firmware for the 3ware 9650 cards and that did not support barriers. But it is true the current firmware does support barriers. I also believe the 3ware StorSave "Performance" setting will disable barriers as well -- at least it makes the card ignore FUA commands. Anyway, I have mounted the XFS filesystem with the "nobarrier" flag and I'm still seeing the same behavior. If you want to take a closer look at what I mean, please go to this link: http://sites.google.com/site/andrewl733info/xfs_and_dpx At this point, I have tried the following -- and none of these approaches seems to fix the problem: -- preallocation of DPX files -- reservation of DXP files (Make 10,000 zero-byte files named 0000001.dpx through 0010000.dpx) -- creating xfs filesystem with external log device (also a 16-drive RAID array, because that's what I have available) -- mounting with large logbsize -- mounting with more logbufs -- mounting with larger allocsize Again, I want to point out that I don't have any problem with the underlying RAID device. On Linux itself, I get Bonnie++ scores of around 740 MB/sec reading and 650 MB/sec writing, minimum. Over 10 Gigabit Ethernet, I can write uncompressed HD streams (160 MB/sec) and I can read 2K DPX files (300+ MB/sec). DD shows similar results. My gut feeling is that XFS is falling over after creating a certain number of new files. Because the DPX format creates one file for every frame (30 files/sec), it's not really a video stream. It's really like making 30 photoshop files per second. It seems as if some resource that XFS needs is being used up after a certain number of files are created, and that it is very disruptive and costly to get more of that resource. Why ext3 and ext4 can keep going past 60,000 files and xfs falls over after 4000 or 5000 files, I do not understand. From aelder@sgi.com Mon Nov 2 15:55:26 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2LtQTh096290 for ; Mon, 2 Nov 2009 15:55:26 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay2.corp.sgi.com (Postfix) with ESMTP id 0F9BB304075; Mon, 2 Nov 2009 13:55:35 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfs: reset the i_iolock lock class in the reclaim path Date: Mon, 2 Nov 2009 15:54:02 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5D@cf--amer001e--3.americas.sgi.com> In-Reply-To: <20091019040526.GC21115@infradead.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] xfs: reset the i_iolock lock class in the reclaim path Thread-Index: AcpQcg52Kz2JU195SYiNJj0dLdp9SwLkXrjw From: "Alex Elder" To: "Christoph Hellwig" Cc: "Peter Zijlstra" , X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > The iolock is used for protecting reads, writes and block truncates = against > each other. We have two classes of callers, the first one is induced = by > a file operation and requires a reference to the inode be held and not > dropped after the operation is done: >=20 > - xfs_vm_vmap, xfs_vn_fallocate, xfs_read, xfs_write, = xfs_splice_read, > xfs_splice_write and xfs_setattr are all implementations of VFS = methods > that require a live inode > - xfs_getbmap and xfs_swap_extents are ioctl subcommand for which the > same is true > - xfs_truncate_file is only called on quota inodes just returned from = xfs_iget > - xfs_sync_inode_data does the lock just after an igrab() > - xfs_filestream_associate and xfs_filestream_new_ag take the iolock = on the > parent inode of an inode which by VFS rules must be referenced >=20 > And we have various calls to truncate blocks past EOF or the whole = file when > dropping the last reference to an inode. Unfortunately lockdep = complains > when we do memory allocations that can recurse into the filesystem in = the > first class because the second class happens to take the same lock. = To avoid > this re-init the iolock in the beginning of xfs_fs_clear_inode to get > a new lock class. >=20 >=20 > Signed-off-by: Christoph Hellwig Looks good. The comment in xfs_fs_clear_inode() is very informative, but it may be emphasizing a lot of detail that doesn't really help the reader at this spot in the code. What about wording something more like this: The iolock is used by the file system to coordinate reads, writes, and block truncates. Up to this point the lock protected concurrent accesses by users of the inode. But from here forward we're doing some final processing of the inode because we're done with it, and although we reuse the iolock for protection it is really a distinct lock class (in the lockdep sense) from before. To keep lockdep happy (and basically indicate what we are doing), we explicitly re-init the iolock here. Reviewed-by: Alex Elder > Index: xfs/fs/xfs/linux-2.6/xfs_super.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2009-10-14 = 17:24:31.356278624 +0200 > +++ xfs/fs/xfs/linux-2.6/xfs_super.c 2009-10-19 06:03:05.771006625 = +0200 > @@ -999,7 +999,6 @@ xfs_fs_inode_init_once( >=20 > mrlock_init(&ip->i_lock, MRLOCK_ALLOW_EQUAL_PRI|MRLOCK_BARRIER, > "xfsino", ip->i_ino); > - mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); > } >=20 > /* > @@ -1101,6 +1100,22 @@ xfs_fs_clear_inode( > XFS_STATS_INC(vn_remove); > XFS_STATS_DEC(vn_active); >=20 > + /* > + * The iolock is used for protecting reads, writes and block = truncates > + * against each other. We have two classes of callers, the first = one > + * is induced by a file operation and requires a reference to the > + * inode be held and not dropped after the operation is done, and > + * second we have various calls to truncate blocks past EOF or for = the > + * whole file when dropping the last reference to an inode. > + * Unfortunately lockdep complains when we do memory allocations = that > + * can recurse into the filesystem in the first class because the > + * second class happens to take the same lock. To avoid this > + * reinitialize the iolock in the beginning of xfs_fs_clear_inode to > + * get a new lock class. > + */ > + ASSERT(!rwsem_is_locked(&ip->i_iolock.mr_lock)); > + mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); > + > xfs_inactive(ip); > } >=20 > Index: xfs/fs/xfs/xfs_iget.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- xfs.orig/fs/xfs/xfs_iget.c 2009-10-14 17:25:26.733004131 +0200 > +++ xfs/fs/xfs/xfs_iget.c 2009-10-14 17:28:26.272274357 +0200 > @@ -73,6 +73,9 @@ xfs_inode_alloc( > ASSERT(atomic_read(&ip->i_pincount) =3D=3D 0); > ASSERT(!spin_is_locked(&ip->i_flags_lock)); > ASSERT(completion_done(&ip->i_flush)); > + ASSERT(!rwsem_is_locked(&ip->i_iolock.mr_lock)); > + > + mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); >=20 > /* initialise the xfs inode */ > ip->i_ino =3D ino; >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From michael.monnerie@is.it-management.at Mon Nov 2 15:58:25 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2LwO1V096646 for ; Mon, 2 Nov 2009 15:58:24 -0600 X-ASG-Debug-ID: 1257199116-131100030000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 782441BA48A7 for ; Mon, 2 Nov 2009 13:58:37 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id bGYD32ew7SzFJEht for ; Mon, 02 Nov 2009 13:58:37 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id DB4E4C02700 for ; Mon, 2 Nov 2009 22:58:35 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id A100040016F for ; Mon, 2 Nov 2009 22:58:35 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files Date: Mon, 2 Nov 2009 22:58:35 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <4AEC2CF4.8040703@aol.com> <200911021205.28006@zmi.at> <20091102185249.0da8e388@harpe.intellique.com> In-Reply-To: <20091102185249.0da8e388@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911022258.35164@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257199117 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13561 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Montag 02 November 2009 Emmanuel Florac wrote: > The 3Ware is so slow it's almost unusable without write cache. I bet > he already uses it anyway. Don't mix up the controller write cache vs. disk write cache. The controller write cache should be on whenever you have a BBM installed, because this brings real performance, while the disk write cache should always be off in a production environment, because you will loose data on power fail, which nobody can recognize (the controller believes the sectors to be written already...) Hence my suggestion for turning on the disk write cache just to see if it makes a difference. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From michael.monnerie@is.it-management.at Mon Nov 2 16:08:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2M8Gss097132 for ; Mon, 2 Nov 2009 16:08:17 -0600 X-ASG-Debug-ID: 1257199709-1310007f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0DD7E180C066 for ; Mon, 2 Nov 2009 14:08:29 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id SOARbVnotIZMtPbn for ; Mon, 02 Nov 2009 14:08:29 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id EC018C02700 for ; Mon, 2 Nov 2009 23:08:26 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id B719B40016F for ; Mon, 2 Nov 2009 23:08:26 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. Subject: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. Date: Mon, 2 Nov 2009 23:08:26 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <7a12b48b0911021202l126e10a1pbc281f6922380f48@mail.gmail.com> In-Reply-To: <7a12b48b0911021202l126e10a1pbc281f6922380f48@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911022308.26282@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257199710 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13561 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Montag 02 November 2009 William Lewis wrote: > Reading your FAQ at http://xfs.org/index.php/XFS_FAQ I understand > that it is advisable to mount the file system with nobarrier to > improve performance. I edited that part, so I'll answer. > However going on to read about recommended > settings for write cache, the advice for 3ware hardware doesn't seem > to account for the fact that there are 2 levels of write cache in > play, that in the 3ware card itself protected by the battery and the > write cache of the disks themselves, There are 2 different caches. One in the controller, on on the disks. > which as far as I can understand > is also protected by the battery backup (in the correct storage modes > - balanced/protection) because the 3ware card uses write journaling > to keep track of pending write operations in the disks' cache. I can't believe it's possible for the controller to know when a disk write is actually on disk while the disk write cache is on. There are lots of disk who plainly *lie* about that fact. I've seen a web page once with a listing of disks who lie - quiet long. I don't find the link ATM, maybe googling helps. > Therefore unless I am misunderstanding something the most benefit is > to be gained by mounting with nobarrier and having the write cache > turned on? If you care about your data, don't turn on the disk write cache. I wonder why there's not a single disk vendor building a disk with a small battery buffer that is able to keep the disk spinning until it can savely empty disk cache to platters. Would be a real performance benefit in server environments. > One thing I am not clear about is if nobarrier interacts with the > page cache at all and if the lack of barrier leaves you with a > situation in which pending writes can be lost from main memory on > power failure? Writes in main RAM will always be lost on power fail. If you need protection for that, use fsync(). The thing about barries is to ensure that metadata is kept consistent on powerfail. It's in fact nothing to protect your data, only the filesystem metadata. Well, in the end your data also, as the filesystem survives. > Thanks in advance for any clarification you can provide. I hope I could help. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From eflorac@intellique.com Mon Nov 2 16:26:20 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2MQJL0097925 for ; Mon, 2 Nov 2009 16:26:19 -0600 X-ASG-Debug-ID: 1257200788-1e08023b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E231014D0C4B for ; Mon, 2 Nov 2009 14:26:29 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by cuda.sgi.com with ESMTP id VF4JFiV50zDAywOU for ; Mon, 02 Nov 2009 14:26:29 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id A8529D48069; Mon, 2 Nov 2009 23:26:25 +0100 (CET) Received: from galadriel.home (pla78-1-82-235-234-79.fbx.proxad.net [82.235.234.79]) by smtp5-g21.free.fr (Postfix) with ESMTP id A860FD480AB; Mon, 2 Nov 2009 23:26:22 +0100 (CET) Date: Mon, 2 Nov 2009 23:26:11 +0100 From: Emmanuel Florac To: "AndrewL733@aol.com" Cc: Michael Monnerie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files Message-ID: <20091102232611.6da5c44f@galadriel.home> In-Reply-To: <4AEF5438.5050801@aol.com> References: <4AEC2CF4.8040703@aol.com> <4AEC4BAA.20606@aol.com> <20091031174836.3fc9505b@galadriel.home> <200911021205.28006@zmi.at> <20091102185249.0da8e388@harpe.intellique.com> <4AEF5438.5050801@aol.com> Organization: Intellique X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp5-g21.free.fr[212.27.42.5] X-Barracuda-Start-Time: 1257200792 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13562 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Mon, 02 Nov 2009 16:50:48 -0500 vous =E9criviez: > It seems as if some resource that=20 > XFS needs is being used up after a certain number of files are > created, and that it is very disruptive and costly to get more of > that resource. Why ext3 and ext4 can keep going past 60,000 files and > xfs falls over after 4000 or 5000 files, I do not understand. I'll do some checks on my side, I have several RAID systems with various RAID controllers (including 3Ware) and a nice "dpx stream" simulator from OPenCube. --=20 -------------------------------------------------- Emmanuel Florac www.intellique.com =20 -------------------------------------------------- From aelder@sgi.com Mon Nov 2 17:21:00 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA2NL07Z102378 for ; Mon, 2 Nov 2009 17:21:00 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay2.corp.sgi.com (Postfix) with ESMTP id 0BA0530407E; Mon, 2 Nov 2009 15:21:11 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfs: use WRITE_SYNC_PLUG for synchronous writeout Date: Mon, 2 Nov 2009 17:20:44 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5E@cf--amer001e--3.americas.sgi.com> In-Reply-To: <20091030090915.GA23188@infradead.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] xfs: use WRITE_SYNC_PLUG for synchronous writeout Thread-Index: AcpZQ3aFAoQDWOTXR0eN2VGoQMCCTwCz5MZw From: "Alex Elder" To: "Christoph Hellwig" Cc: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > The VM and I/O schedulers now expect us to use WRITE_SYNC_PLUG for = synchronous > writeout. Right now I can't see any changes in performance numbers = with this, > but we're getting some beating for not using it, and the knowledge = defintively > could help the block code to make better decisions. >=20 > Signed-off-by: Christoph Hellwig Looks good. Reviewed-by: Alex Elder > Index: linux-2.6/fs/xfs/linux-2.6/xfs_aops.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_aops.c 2009-10-24 = 10:08:36.622254197 +0200 > +++ linux-2.6/fs/xfs/linux-2.6/xfs_aops.c 2009-10-24 = 10:18:27.803006347 +0200 > @@ -412,8 +412,9 @@ xfs_end_bio( >=20 > STATIC void > xfs_submit_ioend_bio( > - xfs_ioend_t *ioend, > - struct bio *bio) > + struct writeback_control *wbc, > + xfs_ioend_t *ioend, > + struct bio *bio) > { > atomic_inc(&ioend->io_remaining); > bio->bi_private =3D ioend; > @@ -426,7 +427,8 @@ xfs_submit_ioend_bio( > if (xfs_ioend_new_eof(ioend)) > xfs_mark_inode_dirty_sync(XFS_I(ioend->io_inode)); >=20 > - submit_bio(WRITE, bio); > + submit_bio(wbc->sync_mode =3D=3D WB_SYNC_ALL ? > + WRITE_SYNC_PLUG : WRITE, bio); > ASSERT(!bio_flagged(bio, BIO_EOPNOTSUPP)); > bio_put(bio); > } > @@ -505,6 +507,7 @@ static inline int bio_add_buffer(struct > */ > STATIC void > xfs_submit_ioend( > + struct writeback_control *wbc, > xfs_ioend_t *ioend) > { > xfs_ioend_t *head =3D ioend; > @@ -533,19 +536,19 @@ xfs_submit_ioend( > retry: > bio =3D xfs_alloc_ioend_bio(bh); > } else if (bh->b_blocknr !=3D lastblock + 1) { > - xfs_submit_ioend_bio(ioend, bio); > + xfs_submit_ioend_bio(wbc, ioend, bio); > goto retry; > } >=20 > if (bio_add_buffer(bio, bh) !=3D bh->b_size) { > - xfs_submit_ioend_bio(ioend, bio); > + xfs_submit_ioend_bio(wbc, ioend, bio); > goto retry; > } >=20 > lastblock =3D bh->b_blocknr; > } > if (bio) > - xfs_submit_ioend_bio(ioend, bio); > + xfs_submit_ioend_bio(wbc, ioend, bio); > xfs_finish_ioend(ioend, 0); > } while ((ioend =3D next) !=3D NULL); > } > @@ -1198,7 +1201,7 @@ xfs_page_state_convert( > } >=20 > if (iohead) > - xfs_submit_ioend(iohead); > + xfs_submit_ioend(wbc, iohead); >=20 > return page_dirty; >=20 >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Mon Nov 2 21:09:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA339MiM116340 for ; Mon, 2 Nov 2009 21:09:22 -0600 X-ASG-Debug-ID: 1257217774-6e3300f30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 80012180C93E for ; Mon, 2 Nov 2009 19:09:34 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id z9AKXcun7JadZ8KN for ; Mon, 02 Nov 2009 19:09:34 -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 mail.sandeen.net (Postfix) with ESMTP id D9C03AAE3B1; Mon, 2 Nov 2009 21:09:33 -0600 (CST) Message-ID: <4AEF9EED.6080403@sandeen.net> Date: Mon, 02 Nov 2009 21:09:33 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "AndrewL733@aol.com" CC: Emmanuel Florac , Michael Monnerie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files References: <4AEC2CF4.8040703@aol.com> <4AEC4BAA.20606@aol.com> <20091031174836.3fc9505b@galadriel.home> <200911021205.28006@zmi.at> <20091102185249.0da8e388@harpe.intellique.com> <4AEF5438.5050801@aol.com> In-Reply-To: <4AEF5438.5050801@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1257217775 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13580 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean AndrewL733@aol.com wrote: > >>> I believe for a 15 drive RAID-6, where 2 disks are used >>> forredundancy, the correct mkfs would be: >>> mkfs -t xfs -d su=65536,sw=13 /dev/sdXX >>> >> >> Yes you're right, I replied a bit too quickly :) >> >> >> >>> Another thing to try is if it would help to turn disk cache writes >>> *on*, despite all warnings if the FAQ. > > Thank you for your suggestions. Yes I have write caching enabled. And I > have StorSave set to "Performance". And I have a UPS on the system at > all times! > > The information about barriers was useful. In years past I was running > much older firmware for the 3ware 9650 cards and that did not support > barriers. But it is true the current firmware does support barriers. I > also believe the 3ware StorSave "Performance" setting will disable > barriers as well -- at least it makes the card ignore FUA commands. > > Anyway, I have mounted the XFS filesystem with the "nobarrier" flag and > I'm still seeing the same behavior. If you want to take a closer look > at what I mean, please go to this link: > > http://sites.google.com/site/andrewl733info/xfs_and_dpx > > At this point, I have tried the following -- and none of these > approaches seems to fix the problem: > > -- preallocation of DPX files > -- reservation of DXP files (Make 10,000 zero-byte files named > 0000001.dpx through 0010000.dpx) > -- creating xfs filesystem with external log device (also a 16-drive > RAID array, because that's what I have available) > -- mounting with large logbsize > -- mounting with more logbufs > -- mounting with larger allocsize Have you said how large the filesystem is? If it's > 1T or 2T, and you're on a 64-bit system, have you tried the inode64 to get nicer inode vs. data allocation behavior? Other suggestions might be to try blktrace/seekwatcher to see where your IO is going, or maybe even oprofile to see if xfs is burning cpu searching for allocations, or somesuch ... -Eric > > Again, I want to point out that I don't have any problem with the > underlying RAID device. On Linux itself, I get Bonnie++ scores of > around 740 MB/sec reading and 650 MB/sec writing, minimum. Over 10 > Gigabit Ethernet, I can write uncompressed HD streams (160 MB/sec) and I > can read 2K DPX files (300+ MB/sec). DD shows similar results. > > My gut feeling is that XFS is falling over after creating a certain > number of new files. Because the DPX format creates one file for every > frame (30 files/sec), it's not really a video stream. It's really like > making 30 photoshop files per second. It seems as if some resource that > XFS needs is being used up after a certain number of files are created, > and that it is very disruptive and costly to get more of that resource. > Why ext3 and ext4 can keep going past 60,000 files and xfs falls over > after 4000 or 5000 files, I do not understand. > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From Emma.Helin@stud.aho.no Tue Nov 3 01:08:40 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA378d6k133249 for ; Tue, 3 Nov 2009 01:08:40 -0600 X-ASG-Debug-ID: 1257232130-272302f40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from loos.aho.no (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 777F314D1FF6 for ; Mon, 2 Nov 2009 23:08:50 -0800 (PST) Received: from loos.aho.no (robinhood.aho.no [158.36.153.18]) by cuda.sgi.com with ESMTP id 1bRbUyjCXMFtCojG for ; Mon, 02 Nov 2009 23:08:50 -0800 (PST) Received: from bull.aho.local (158.36.94.10) by loos.aho.no (158.36.153.18) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 3 Nov 2009 08:08:49 +0100 Received: from bull.aho.local ([158.36.94.11]) by bull.aho.local ([158.36.94.11]) with mapi; Tue, 3 Nov 2009 08:08:48 +0100 From: "Emma K. Helin" Date: Tue, 3 Nov 2009 08:08:47 +0100 X-ASG-Orig-Subj: Shipment Code: CPEL/OWN/9856 Subject: Shipment Code: CPEL/OWN/9856 Thread-Topic: Shipment Code: CPEL/OWN/9856 Thread-Index: AQHKXFR9JaT5EZZAiEmZu5kckTfbUA== Message-ID: <3501A64D73C23C4E96962A9B288BE17181A7440223@bull.aho.local> Accept-Language: en-US, nb-NO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, nb-NO Content-Type: multipart/alternative; boundary="_000_3501A64D73C23C4E96962A9B288BE17181A7440223bullaholocal_" MIME-Version: 1.0 To: Undisclosed recipients:; X-Barracuda-Connect: robinhood.aho.no[158.36.153.18] X-Barracuda-Start-Time: 1257232132 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4999 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13596 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --_000_3501A64D73C23C4E96962A9B288BE17181A7440223bullaholocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Greetings, I have been trying to reach you for sometime now, so i just want to inform = you that I have deposited your ATM MASTER CARD of =A3800,000,00 GBP, Great = British Pounds to the Fedex Delivery services here in United Kingdom, and i= packaged the ATM MASTER CARD inside a magazine where nobody will notice th= e content. Insurance and delivery charges have been paid for, but the only = fee remaining is the security safe keeping fee of =A3255,00 British Pounds = only, which you will be required to pay before delivery. However, this was not paid for because of demurrage. Well, I did forward th= em your delivery address, but a re-confirmation is important when contactin= g them if you want to change your address. I advice you quote the parcel an= d shipment code to them for onward delivery to your re-confirmed address.Th= e ATM MASTERCARD has pin number 1474. Please make sure you contact the ship= ment officer through his correct email below. Contact the shipment office with the below informations and re-confirm your= correct address details: Full name...................... Home address............ Country.................... Telephone............... Attention: Mr. Collins Oliver Shipment Officer Of Fedex delivery services U= nited Kingdom. E-mail: dispatch.dept@administrativos.com Tel: +447035945165 Shipment Code: CPEL/OWN/9856 Parcel Number: EG2272-UK I do hope you'll take care of this transaction as soon as possible. Unfortu= nately you will not be able to reach me as I've been called out of the coun= try on business for 4 months. Once again, the Fedex delivery services do no= t know the content of the parcel, I registered it as an United Kingdom maga= zine they don't know it contains ATM MASTERCARD inside, this is to avoid th= em delaying the delivery and besides I don't want you to lose your inheritt= ance funds. Remain blessed and enjoy your funds. Barr. Greg Williams. --_000_3501A64D73C23C4E96962A9B288BE17181A7440223bullaholocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=  
Greetings,

I have been trying to reach you for sometime now, so i just want to inform = you that I have deposited your ATM MASTER CARD of =A3800,000,00 GBP,&n= bsp;Great British Pounds to the Fedex Delivery services here in United= Kingdom, and i packaged the ATM MASTER CARD inside a magazine where nobody will notice the content. Insurance and delivery ch= arges have been paid for, but the only fee remaining is the security safe k= eeping fee of =A3255,00 British Pounds only, which you will be re= quired to pay before delivery.

However, this was not paid for because of demurrage. Well, I did forward th= em your delivery address, but a re-confirmation is important when contactin= g them if you want to change your address. I advice you quote the parcel an= d shipment code to them for onward delivery to your re-confirmed address.The ATM MASTERCARD has pin number 14= 74. Please make sure you contact the shipment officer through his correct e= mail below.

Contact the shipment office with the below informations and re-confirm your= correct address details:

Full name......................
Home address............
Country....................
Telephone...............

Attention: Mr. Collins Oliver Shipment Officer Of Fedex delivery services U= nited Kingdom.
E-mail: dispatch.dept@= administrativos.com
Tel: +447035945165

Shipment Code: CPEL/OWN/9856
Parcel Number: EG2272-UK

I do hope you'll take care of this transaction as soon as possible. Unfortu= nately you will not be able to reach me as I've been called out of the coun= try on business for 4 months. Once again, the Fedex delivery services do no= t know the content of the parcel, I registered it as an United Kingdom magazine they don't know it= contains ATM MASTERCARD inside, this is to avoid them delaying the deliver= y and besides I don't want you to lose your inherittance funds.

Remain blessed and enjoy your funds.
Barr. Greg Williams.
--_000_3501A64D73C23C4E96962A9B288BE17181A7440223bullaholocal_-- From michael.monnerie@is.it-management.at Tue Nov 3 02:36:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA38aGoE137942 for ; Tue, 3 Nov 2009 02:36:17 -0600 X-ASG-Debug-ID: 1257237387-7c13006c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DB9B857C4C for ; Tue, 3 Nov 2009 00:36:27 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id On5NVQ5Rjyz66Q8P for ; Tue, 03 Nov 2009 00:36:27 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id 15F41C3AB07 for ; Tue, 3 Nov 2009 09:36:26 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id D81D340016F for ; Tue, 3 Nov 2009 09:36:25 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. Subject: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options. Date: Tue, 3 Nov 2009 09:36:25 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <7a12b48b0911021202l126e10a1pbc281f6922380f48@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200911030936.25442@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257237387 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13600 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Montag 02 November 2009 Justin Piszcz wrote: > I am also curious, I have a 16 drive RAID-6 configuration on a > 9650SE-16ML and using -o nobarrier or mounting normal the > speed/benchmarks seemed to be the same. =A0Either barriers are not > enabled by default for 3ware RAID arrays or they make no difference > in performance? I'd say a RAID controller with it's own write cache enabled + BBM will=20 effectively turn barriers off, even if you can use them as a mount=20 options. What happens with barriers, is that it writes=20 1,2,3,barrier,4,5,barrier,6 etc. so, that 123 are sure on disk before 45=20 happen etc. The RAID controller will happily tell you it did flush everything,=20 because as soon as data is in it's cache, it's claimed sure that the=20 data gets written, and therefore it will tell that the barrier is=20 already done. And that's why it's a *must* to turn off disk cache=20 writes, because the filesystem got it's barrier ACK and believes it, the=20 controller has it's cache written to disk, powerfail.... all gone. That=20 will do a bigger damage than any single disk could have done. mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From eflorac@intellique.com Tue Nov 3 05:19:38 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_BRBL autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3BJcG0149290 for ; Tue, 3 Nov 2009 05:19:38 -0600 X-ASG-Debug-ID: 1257247163-1a7802b50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EF0F7180DDD5 for ; Tue, 3 Nov 2009 03:19:24 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by cuda.sgi.com with ESMTP id mwa7DFtc5k4EPpTW for ; Tue, 03 Nov 2009 03:19:24 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 924384B0149; Tue, 3 Nov 2009 12:19:20 +0100 (CET) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by smtp2-g21.free.fr (Postfix) with ESMTP id 9E42E4B01A8; Tue, 3 Nov 2009 12:19:18 +0100 (CET) Date: Tue, 3 Nov 2009 12:19:20 +0100 From: Emmanuel Florac To: Michael Monnerie Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files Message-ID: <20091103121920.7e6b6d07@harpe.intellique.com> In-Reply-To: <200911022258.35164@zmi.at> References: <4AEC2CF4.8040703@aol.com> <200911021205.28006@zmi.at> <20091102185249.0da8e388@harpe.intellique.com> <200911022258.35164@zmi.at> Organization: Intellique X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp2-g21.free.fr[212.27.42.2] X-Barracuda-Start-Time: 1257247167 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13610 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Mon, 2 Nov 2009 22:58:35 +0100 Michael Monnerie =E9crivait: > Hence my suggestion for turning on the disk write cache just to see > if it makes a difference. Unfortunately there isn't any way in the 3Ware controllers to manage that. Worse, I couldn't get a clear answer from 3Ware support about the controller policy about drives caches. However from the tests I've done (pulling the plug on a server while writing) it looks like the 3Ware uses the disks caches in write-thru mode, however (fortunately now that many drives come with 32 or 64 MB caches).=20 Some other SATA/SAS RAID controllers (Areca, LSI and Adaptec) allows to activate drive write-back cache separately from the controller cache, though. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Intellique ------------------------------------------------------------------------ From BATV+d025d950ee54ecc9cd14+2263+infradead.org+hch@bombadil.srs.infradead.org Tue Nov 3 08:45:42 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3Ejepw166899 for ; Tue, 3 Nov 2009 08:45:42 -0600 X-ASG-Debug-ID: 1257259554-5fc203330000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A0D7459493; Tue, 3 Nov 2009 06:45:54 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 2ov36zeoayMYQ0O2; Tue, 03 Nov 2009 06:45:54 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1N5Kdm-0002IC-8p; Tue, 03 Nov 2009 14:45:47 +0000 Date: Tue, 3 Nov 2009 09:45:46 -0500 From: Christoph Hellwig To: Alex Elder Cc: Christoph Hellwig , Thomas Neumann , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: I/O completion handlers must use NOFS allocations Subject: Re: [PATCH] xfs: I/O completion handlers must use NOFS allocations Message-ID: <20091103144545.GA32542@infradead.org> References: <20091019040003.GA21115@infradead.org> <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5B@cf--amer001e--3.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5B@cf--amer001e--3.americas.sgi.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1257259554 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 02, 2009 at 02:34:01PM -0600, Alex Elder wrote: > This looks good. It's kind of too bad the GFP_ flag > argument had to be added, but I can't think of a cleaner > way than the way you did it. The slightly better way would be to set the PF_FSTRANS flag for the workqueue threads, but the workqueue interfaces that allows setting these flags were removed a while ago. > I have one minor suggestion on wording used in a comment, > but the code looks correct to me. I verified that--as you > say--the only place we're doing an allocation in an I/O > completion handler (i.e., a function called via > io_end->io_work->func) is in xfs_iomap_write_unwritten(), > so this fix should cover the only case. > > + * Note that we opencoding the transaction allocation here > > + * to pass KM_NOFS - we can't risk to recurse back into > > > How about, "we can't risk recursing back into" Fine with me. Do you want me to resend or are you going to fix it up on fly before applying the patch? From patrick@news-service.com Tue Nov 3 08:45:43 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3Ejf4H166901 for ; Tue, 3 Nov 2009 08:45:42 -0600 X-ASG-Debug-ID: 1257259553-274e027c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pu01.news-service.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60F3514D3398 for ; Tue, 3 Nov 2009 06:45:54 -0800 (PST) Received: from pu01.news-service.com (ns1.news-service.com [195.114.240.3]) by cuda.sgi.com with ESMTP id F9sky96e7DklJESI for ; Tue, 03 Nov 2009 06:45:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by pu01.news-service.com (Postfix) with ESMTP id 3D423629C0; Tue, 3 Nov 2009 15:45:53 +0100 (CET) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at pu01.news-service.com Received: from pu01.news-service.com ([127.0.0.1]) by localhost (pu01.nse [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q00jUOQSDcIp; Tue, 3 Nov 2009 15:45:51 +0100 (CET) Received: from [172.25.0.47] (nse01.nse [172.25.0.47]) by pu01.news-service.com (Postfix) with ESMTP id 3897B629BC; Tue, 3 Nov 2009 15:45:51 +0100 (CET) Message-ID: <4AF0422D.1070104@news-service.com> Date: Tue, 03 Nov 2009 15:46:05 +0100 From: Patrick Schreurs User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christoph Hellwig CC: Tommy van Leeuwen , Bas Couwenberg , XFS List X-ASG-Orig-Subj: Re: 2.6.31 xfs_fs_destroy_inode: cannot reclaim Subject: Re: 2.6.31 xfs_fs_destroy_inode: cannot reclaim References: <20091007011926.GB32032@infradead.org> <4AD18C8D.90808@news-service.com> <20091012233854.GA29446@infradead.org> <20091019011600.GO9464@discord.disaster> <20091019035426.GB18296@infradead.org> <20091020034048.GA9464@discord.disaster> <89c4f90c0910210245h4691cd82hd1d63f5ed72fb2e3@mail.gmail.com> <20091022085937.GA2039@infradead.org> <89c4f90c0910270341r7833f490g60810f2817eb0950@mail.gmail.com> <89c4f90c0910280519k759230c1r7b1586932ac792f7@mail.gmail.com> <20091030101601.GA11142@infradead.org> In-Reply-To: <20091030101601.GA11142@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ns1.news-service.com[195.114.240.3] X-Barracuda-Start-Time: 1257259555 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0203 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13623 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean Christoph Hellwig wrote: > On Wed, Oct 28, 2009 at 01:19:44PM +0100, Tommy van Leeuwen wrote: >> Another one just seconds ago. Might be more usefull then the last 2. > > Ist this one also with COFNIG_XFS_DEBUG enabled? May assert should have > hit the condition we're seing in that one earlier. Sorry for the delay. Yes, XFS_DEBUG was enabled on these servers. > Anyway, it still looks like we can get inodes that are partially > or fully torn down before entering ->destroy_inode. I'll try to figure > out why. We're back to 2.6.28 at the moment. Please advice if we can do anything to assist. Any clue why we seem to be the only one hitting this problem? It might have something to do with the short term data retention on these particular servers. All partitions are always 100% full and data is only kept for a couple of days. Thanks for looking into this. -Patrick From BATV+d025d950ee54ecc9cd14+2263+infradead.org+hch@bombadil.srs.infradead.org Tue Nov 3 08:51:39 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3Epcl0167256 for ; Tue, 3 Nov 2009 08:51:39 -0600 X-ASG-Debug-ID: 1257259912-7a5a02150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 18782591EE; Tue, 3 Nov 2009 06:51:52 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id KXbxw4t8F8Qqdm28; Tue, 03 Nov 2009 06:51:52 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1N5Kjg-0000Lx-In; Tue, 03 Nov 2009 14:51:52 +0000 Date: Tue, 3 Nov 2009 09:51:52 -0500 From: Christoph Hellwig To: Alex Elder Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: fix mmap_sem vs iolock lock order inversion inxfs_free_eofblocks Subject: Re: [PATCH] xfs: fix mmap_sem vs iolock lock order inversion inxfs_free_eofblocks Message-ID: <20091103145152.GB32542@infradead.org> References: <20091019040346.GB21115@infradead.org> <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5C@cf--amer001e--3.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5C@cf--amer001e--3.americas.sgi.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1257259913 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 02, 2009 at 03:10:33PM -0600, Alex Elder wrote: > I have a minor suggestion below, but it looks correct to me. > I tried to get a better idea of what the conditions were > where mmap_sem would be held by VM when ->release gets > called, but didn't get to the bottom of that. If it is > easily characterized you could mention it in comments. It's the VMA merging code. But IMHO that's too much of an implementation detail to put into the comment here. Commit message might be fine. From BATV+d025d950ee54ecc9cd14+2263+infradead.org+hch@bombadil.srs.infradead.org Tue Nov 3 08:55:47 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3EtlV6167443 for ; Tue, 3 Nov 2009 08:55:47 -0600 X-ASG-Debug-ID: 1257260160-32e003be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 638B21D8CC15; Tue, 3 Nov 2009 06:56:00 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id RJTrewy4cmjzEPd2; Tue, 03 Nov 2009 06:56:00 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1N5Knf-0003f3-MO; Tue, 03 Nov 2009 14:55:59 +0000 Date: Tue, 3 Nov 2009 09:55:59 -0500 From: Christoph Hellwig To: Alex Elder Cc: Christoph Hellwig , Peter Zijlstra , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: reset the i_iolock lock class in the reclaim path Subject: Re: [PATCH] xfs: reset the i_iolock lock class in the reclaim path Message-ID: <20091103145559.GC32542@infradead.org> References: <20091019040526.GC21115@infradead.org> <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5D@cf--amer001e--3.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5D@cf--amer001e--3.americas.sgi.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1257260161 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 02, 2009 at 03:54:02PM -0600, Alex Elder wrote: > The comment in xfs_fs_clear_inode() is very informative, but > it may be emphasizing a lot of detail that doesn't really > help the reader at this spot in the code. What about wording > something more like this: > The iolock is used by the file system to coordinate > reads, writes, and block truncates. Up to this point > the lock protected concurrent accesses by users of > the inode. But from here forward we're doing some final > processing of the inode because we're done with it, > and although we reuse the iolock for protection it is > really a distinct lock class (in the lockdep sense) from > before. To keep lockdep happy (and basically indicate > what we are doing), we explicitly re-init the iolock here. Fine with me. Do you want a respin or will you fix up the comment on the fly? From noreply@wconnector.com Tue Nov 3 09:14:07 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_50,DEAR_SOMETHING autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3FE7v2168400 for ; Tue, 3 Nov 2009 09:14:07 -0600 X-ASG-Debug-ID: 1257261259-53cc00000000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wconnector.wconnector.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 845A41D8CFB5 for ; Tue, 3 Nov 2009 07:14:19 -0800 (PST) Received: from wconnector.wconnector.com (22.1d.364a.static.theplanet.com [74.54.29.34]) by cuda.sgi.com with ESMTP id UEubvTCC8HZV9CDQ for ; Tue, 03 Nov 2009 07:14:19 -0800 (PST) Received: from wconnect by wconnector.wconnector.com with local (Exim 4.69) (envelope-from ) id 1N5L5N-0001vc-QF for linux-xfs@oss.sgi.com; Tue, 03 Nov 2009 18:14:17 +0300 To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Leading Yemen Importers and Exporters Subject: Leading Yemen Importers and Exporters X-PHP-Script: www.wconnector.com/phplist/admin/index.php for 74.54.29.34 Recieved: Date: Tue, 3 Nov 2009 18:14:17 +0300 From: Yemen Business Directory Message-ID: <89bdb7f530375f4b3733e3c5d6be914c@www.wconnector.com> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] X-Mailer: phplist v2.10.10 X-MessageID: 1 X-ListMember: linux-xfs@oss.sgi.com Precedence: bulk Errors-To: noreply@wconnector.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wconnector.wconnector.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [510 32003] / [47 12] X-AntiAbuse: Sender Address Domain - wconnector.com X-Source: /usr/bin/php X-Source-Args: /usr/bin/php /home/wconnect/public_html/phplist/admin/index.php X-Source-Dir: wconnector.com:/public_html/phplist/admin X-Barracuda-Connect: 22.1d.364a.static.theplanet.com[74.54.29.34] X-Barracuda-Start-Time: 1257261260 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4592 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13624 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dear sir, We would like to invite you to visit the Official Website of the Yemen Business Directory: http://wconnector.com/phplist/lt.php?id=ZkQFUAkGB1JdSAVJBg8AU1AP It contains very useful informative stuffs about: Complete addresses and contact details of Leading Yemeni Importer and Exporter Companies. As well As Databank full of information about Yemen: 1. Investment Opportunities and Laws. 2. Legislative info and Commercial and Trade Laws 3. Wide Range of Statistical Information 4. Custom duties, Taxes 5. Economy 6. Oil, Minerals and Gas. 7. Population and manpower. 8. Export market 9. Industry, Fish Treasury, Agriculture. 10.Travel and Tourism Wishing you a nice visit to our Website Best regards. Yemen Business Directory International Promotion Team Tel: +967-1-254132 Fax: +967-1-252998 Sana’a - Yemen Business http://wconnector.com/phplist/lt.php?id=ZkQFUAkGB1JdSAVJBg8AU1AP -- If you do not want to receive any more newsletters, http://wconnector.com/phplist/lt.php?id=ZkQFUAkGB1NUSAVJBg8AU1AP Forward a Message to Someone http://wconnector.com/phplist/lt.php?id=ZkQFUAkGB1NVSAVJBg8AU1AP -- Powered by PHPlist, www.phplist.com -- From BATV+d025d950ee54ecc9cd14+2263+infradead.org+hch@bombadil.srs.infradead.org Tue Nov 3 09:50:08 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3Fo6GT170177 for ; Tue, 3 Nov 2009 09:50:08 -0600 X-ASG-Debug-ID: 1257263419-70fd00180000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E3FEC59D94 for ; Tue, 3 Nov 2009 07:50:19 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Baw8cy3xcR51oT1D for ; Tue, 03 Nov 2009 07:50:19 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1N5LeF-0007t3-Iu for xfs@oss.sgi.com; Tue, 03 Nov 2009 15:50:19 +0000 Date: Tue, 3 Nov 2009 10:50:19 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] db: stop using xfs_bmbt_rec_32_t Subject: [PATCH] db: stop using xfs_bmbt_rec_32_t Message-ID: <20091103155019.GA28991@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1257263419 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean xfs_db uses the xfs_bmbt_rec_32_t type to pass around extent information in a few places. But everywhere where we actually use it we use the normal xfs_bmbt_rec_t just casting from/to xfs_bmbt_rec_32_t to pass it around. Just pass the xfs_bmbt_rec_t directly and thus get rid of the last use of xfs_bmbt_rec_32_t in xfsprogs. Signed-off-by: Christoph Hellwig Index: xfsprogs-dev/db/check.c =================================================================== --- xfsprogs-dev.orig/db/check.c 2009-10-11 03:16:17.350004081 +0200 +++ xfsprogs-dev/db/check.c 2009-11-03 16:46:56.067277983 +0100 @@ -265,7 +265,7 @@ static int ncheck_f(int argc, char **ar static char *prepend_path(char *oldpath, char *parent); static xfs_ino_t process_block_dir_v2(blkmap_t *blkmap, int *dot, int *dotdot, inodata_t *id); -static void process_bmbt_reclist(xfs_bmbt_rec_32_t *rp, int numrecs, +static void process_bmbt_reclist(xfs_bmbt_rec_t *rp, int numrecs, dbm_t type, inodata_t *id, xfs_drfsbno_t *tot, blkmap_t **blkmapp); @@ -2012,7 +2012,7 @@ process_block_dir_v2( static void process_bmbt_reclist( - xfs_bmbt_rec_32_t *rp, + xfs_bmbt_rec_t *rp, int numrecs, dbm_t type, inodata_t *id, @@ -2038,7 +2038,7 @@ process_bmbt_reclist( iagno = XFS_INO_TO_AGNO(mp, id->ino); iagbno = XFS_INO_TO_AGBNO(mp, id->ino); for (i = 0; i < numrecs; i++, rp++) { - convert_extent((xfs_bmbt_rec_64_t *)rp, &o, &s, &c, &f); + convert_extent(rp, &o, &s, &c, &f); if (v) dbprintf(_("inode %lld extent [%lld,%lld,%lld,%d]\n"), id->ino, o, s, c, f); @@ -2120,7 +2120,6 @@ process_btinode( xfs_bmdr_block_t *dib; int i; xfs_bmbt_ptr_t *pp; - xfs_bmbt_rec_32_t *rp; dib = (xfs_bmdr_block_t *)XFS_DFORK_PTR(dip, whichfork); if (be16_to_cpu(dib->bb_level) >= XFS_BM_MAXLEVELS(mp, whichfork)) { @@ -2146,7 +2145,7 @@ process_btinode( return; } if (be16_to_cpu(dib->bb_level) == 0) { - rp = (xfs_bmbt_rec_32_t *)XFS_BMDR_REC_ADDR(dib, 1); + xfs_bmbt_rec_t *rp = XFS_BMDR_REC_ADDR(dib, 1); process_bmbt_reclist(rp, be16_to_cpu(dib->bb_numrecs), type, id, totd, blkmapp); *nex += be16_to_cpu(dib->bb_numrecs); @@ -2579,12 +2578,12 @@ process_exinode( blkmap_t **blkmapp, int whichfork) { - xfs_bmbt_rec_32_t *rp; + xfs_bmbt_rec_t *rp; - rp = (xfs_bmbt_rec_32_t *)XFS_DFORK_PTR(dip, whichfork); + rp = (xfs_bmbt_rec_t *)XFS_DFORK_PTR(dip, whichfork); *nex = XFS_DFORK_NEXTENTS(dip, whichfork); if (*nex < 0 || *nex > XFS_DFORK_SIZE(dip, mp, whichfork) / - sizeof(xfs_bmbt_rec_32_t)) { + sizeof(xfs_bmbt_rec_t)) { if (!sflag || id->ilist) dbprintf(_("bad number of extents %d for inode %lld\n"), *nex, id->ino); @@ -4207,7 +4206,7 @@ scanfunc_bmap( xfs_agnumber_t agno; int i; xfs_bmbt_ptr_t *pp; - xfs_bmbt_rec_32_t *rp; + xfs_bmbt_rec_t *rp; agno = XFS_FSB_TO_AGNO(mp, bno); agbno = XFS_FSB_TO_AGBNO(mp, bno); @@ -4240,7 +4239,7 @@ scanfunc_bmap( error++; return; } - rp = (xfs_bmbt_rec_32_t *)XFS_BMBT_REC_ADDR(mp, block, 1); + rp = XFS_BMBT_REC_ADDR(mp, block, 1); *nex += be16_to_cpu(block->bb_numrecs); process_bmbt_reclist(rp, be16_to_cpu(block->bb_numrecs), type, id, totd, blkmapp); Index: xfsprogs-dev/db/frag.c =================================================================== --- xfsprogs-dev.orig/db/frag.c 2009-10-11 03:16:17.364007469 +0200 +++ xfsprogs-dev/db/frag.c 2009-11-03 16:46:56.068277413 +0100 @@ -66,7 +66,7 @@ static void extmap_set_ext(extmap_t **e xfs_extlen_t c); static int frag_f(int argc, char **argv); static int init(int argc, char **argv); -static void process_bmbt_reclist(xfs_bmbt_rec_32_t *rp, int numrecs, +static void process_bmbt_reclist(xfs_bmbt_rec_t *rp, int numrecs, extmap_t **extmapp); static void process_btinode(xfs_dinode_t *dip, extmap_t **extmapp, int whichfork); @@ -223,7 +223,7 @@ init( static void process_bmbt_reclist( - xfs_bmbt_rec_32_t *rp, + xfs_bmbt_rec_t *rp, int numrecs, extmap_t **extmapp) { @@ -234,7 +234,7 @@ process_bmbt_reclist( xfs_dfsbno_t s; for (i = 0; i < numrecs; i++, rp++) { - convert_extent((xfs_bmbt_rec_64_t *)rp, &o, &s, &c, &f); + convert_extent(rp, &o, &s, &c, &f); extmap_set_ext(extmapp, (xfs_fileoff_t)o, (xfs_extlen_t)c); } } @@ -248,11 +248,10 @@ process_btinode( xfs_bmdr_block_t *dib; int i; xfs_bmbt_ptr_t *pp; - xfs_bmbt_rec_32_t *rp; dib = (xfs_bmdr_block_t *)XFS_DFORK_PTR(dip, whichfork); if (be16_to_cpu(dib->bb_level) == 0) { - rp = (xfs_bmbt_rec_32_t *)XFS_BMDR_REC_ADDR(dib, 1); + xfs_bmbt_rec_t *rp = XFS_BMDR_REC_ADDR(dib, 1); process_bmbt_reclist(rp, be16_to_cpu(dib->bb_numrecs), extmapp); return; } @@ -270,9 +269,9 @@ process_exinode( extmap_t **extmapp, int whichfork) { - xfs_bmbt_rec_32_t *rp; + xfs_bmbt_rec_t *rp; - rp = (xfs_bmbt_rec_32_t *)XFS_DFORK_PTR(dip, whichfork); + rp = (xfs_bmbt_rec_t *)XFS_DFORK_PTR(dip, whichfork); process_bmbt_reclist(rp, XFS_DFORK_NEXTENTS(dip, whichfork), extmapp); } @@ -448,8 +447,7 @@ scanfunc_bmap( return; } rp = XFS_BMBT_REC_ADDR(mp, block, 1); - process_bmbt_reclist((xfs_bmbt_rec_32_t *)rp, - nrecs, extmapp); + process_bmbt_reclist(rp, nrecs, extmapp); return; } From aelder@sgi.com Tue Nov 3 10:18:25 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3GIOX8171757 for ; Tue, 3 Nov 2009 10:18:24 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay3.corp.sgi.com (Postfix) with ESMTP id 88E33AC004; Tue, 3 Nov 2009 08:18:35 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfs: cleanup data end I/O handlers Date: Tue, 3 Nov 2009 10:18:34 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE62@cf--amer001e--3.americas.sgi.com> In-Reply-To: <20091030091147.GB23188@infradead.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] xfs: cleanup data end I/O handlers Thread-Index: AcpZQ3YJp6PbpT0pStKvWUv2b9KuvQDVljeQ From: "Alex Elder" To: "Christoph Hellwig" Cc: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig wrote: > Currently we have various different end I/O handler for read vs the = different > types of write I/O. But they are all very similar so we could just = use one > with a few conditionals and reduce code size a lot. When I was looking at the last patch I had the same thought, so I'm glad you did this. The patch is good--here are a few thoughts so you can correct me if I'm misunderstanding something... I note that you now call xfs_setfilesize() in the IOMAP_UNWRITTEN case even if there was an I/O error indicated, which is different from current code. But that's OK because xfs_setfilesize() checks for that condition, so the result is the same. I also note that you no longer init the work queue at the end of a non-extending direct I/O write. But that too is OK, because it looks like the only reason it was initialized there was so that the work function pointer would change, for the benefit of xfs_finish_ioend(). But you changed that to make use of the io_type, which is a better way of doing it anyway. In summary... Looks good, I like it. > Signed-off-by: Christoph Hellwig Reviewed-by: Alex Elder > Index: linux-2.6/fs/xfs/linux-2.6/xfs_aops.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_aops.c 2009-10-30 = 10:05:46.680256053 +0100 > +++ linux-2.6/fs/xfs/linux-2.6/xfs_aops.c 2009-10-30 = 10:08:54.235024030 +0100 > @@ -235,71 +235,36 @@ xfs_setfilesize( > } >=20 > /* > - * Buffered IO write completion for delayed allocate extents. > + * IO write completion. > */ > STATIC void > -xfs_end_bio_delalloc( > - struct work_struct *work) > -{ > - xfs_ioend_t *ioend =3D > - container_of(work, xfs_ioend_t, io_work); > - > - xfs_setfilesize(ioend); > - xfs_destroy_ioend(ioend); > -} > - > -/* > - * Buffered IO write completion for regular, written extents. > - */ > -STATIC void > -xfs_end_bio_written( > - struct work_struct *work) > -{ > - xfs_ioend_t *ioend =3D > - container_of(work, xfs_ioend_t, io_work); > - > - xfs_setfilesize(ioend); > - xfs_destroy_ioend(ioend); > -} > - > -/* > - * IO write completion for unwritten extents. > - * > - * Issue transactions to convert a buffer range from unwritten > - * to written extents. > - */ > -STATIC void > -xfs_end_bio_unwritten( > +xfs_end_io( > struct work_struct *work) > { > xfs_ioend_t *ioend =3D > container_of(work, xfs_ioend_t, io_work); > struct xfs_inode *ip =3D XFS_I(ioend->io_inode); > - xfs_off_t offset =3D ioend->io_offset; > - size_t size =3D ioend->io_size; >=20 > - if (likely(!ioend->io_error)) { > - if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) { > - int error; > - error =3D xfs_iomap_write_unwritten(ip, offset, size); > - if (error) > - ioend->io_error =3D error; > - } > - xfs_setfilesize(ioend); > + /* > + * For unwritten extents we need to issue transactions to convert a > + * range to normal written extens after the data I/O has finished. > + */ > + if (ioend->io_type =3D=3D IOMAP_UNWRITTEN && > + likely(!ioend->io_error && !XFS_FORCED_SHUTDOWN(ip->i_mount))) { > + int error; > + > + error =3D xfs_iomap_write_unwritten(ip, ioend->io_offset, > + ioend->io_size); > + if (error) > + ioend->io_error =3D error; > } > - xfs_destroy_ioend(ioend); > -} > - > -/* > - * IO read completion for regular, written extents. > - */ > -STATIC void > -xfs_end_bio_read( > - struct work_struct *work) > -{ > - xfs_ioend_t *ioend =3D > - container_of(work, xfs_ioend_t, io_work); >=20 > + /* > + * We might have to update the on-disk file size after extending > + * writes. > + */ > + if (ioend->io_type !=3D IOMAP_READ) > + xfs_setfilesize(ioend); > xfs_destroy_ioend(ioend); > } >=20 > @@ -314,10 +279,10 @@ xfs_finish_ioend( > int wait) > { > if (atomic_dec_and_test(&ioend->io_remaining)) { > - struct workqueue_struct *wq =3D xfsdatad_workqueue; > - if (ioend->io_work.func =3D=3D xfs_end_bio_unwritten) > - wq =3D xfsconvertd_workqueue; > + struct workqueue_struct *wq; >=20 > + wq =3D (ioend->io_type =3D=3D IOMAP_UNWRITTEN) ? > + xfsconvertd_workqueue : xfsdatad_workqueue; > queue_work(wq, &ioend->io_work); > if (wait) > flush_workqueue(wq); > @@ -355,15 +320,7 @@ xfs_alloc_ioend( > ioend->io_offset =3D 0; > ioend->io_size =3D 0; >=20 > - if (type =3D=3D IOMAP_UNWRITTEN) > - INIT_WORK(&ioend->io_work, xfs_end_bio_unwritten); > - else if (type =3D=3D IOMAP_DELAY) > - INIT_WORK(&ioend->io_work, xfs_end_bio_delalloc); > - else if (type =3D=3D IOMAP_READ) > - INIT_WORK(&ioend->io_work, xfs_end_bio_read); > - else > - INIT_WORK(&ioend->io_work, xfs_end_bio_written); > - > + INIT_WORK(&ioend->io_work, xfs_end_io); > return ioend; > } >=20 > @@ -1538,7 +1495,7 @@ xfs_end_io_direct( > * didn't map an unwritten extent so switch it's completion > * handler. > */ > - INIT_WORK(&ioend->io_work, xfs_end_bio_written); > + ioend->io_type =3D IOMAP_NEW; > xfs_finish_ioend(ioend, 0); > } >=20 >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From aelder@sgi.com Tue Nov 3 11:26:37 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3HQbTX175498 for ; Tue, 3 Nov 2009 11:26:37 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay3.corp.sgi.com (Postfix) with ESMTP id D0D45AC004; Tue, 3 Nov 2009 09:26:47 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [PATCH] xfs: Wrapped journal record corruption on read at recovery Date: Tue, 3 Nov 2009 11:26:47 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE64@cf--amer001e--3.americas.sgi.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wrapped journal record corruption on read at recovery - patchattached (was Re: XFS corruption with failover) Thread-Index: AcpN+Tuft9jB9P80QiemylsfQMjH1QOsCBNQ From: "Alex Elder" To: Cc: "Andy Poling" , "John Quigley" X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Andy Poling wrote: > On Wed, 14 Oct 2009, Christoph Hellwig wrote: >>> It seems like the more elegant approach would be to set offset = before the >>> first read, and then update it if the first read takes place (in = case it was >>> unaligned). That also gets rid of bufaddr, and seems like it might = read >>> better. >>=20 >> Yeah. Note that in Linux 2.6.29 I did some changes in that are to >> take the read and offset calculation into a common helper >=20 > Looking at the improved code since 2.6.29, and assuming that the = beginning of > the log will always be aligned, I have come up with the attached patch = against > 2.6.31.4. I think it's cleaner, and it passes my tests. >=20 > The bufaddr variable is no longer needed. I removed the xlog_align() = after > the second read for both headers and data since the second read will = always be > aligned (even if there was no first read) since it is always at the = beginning > of the log. >=20 > It sets offset to the beginning of the buffer with XFS_BUF_PTR() = before the > first read, and then your improved xlog_bread() will update the offset = if the > first read had to be re-aligned. >=20 > What do you think? >=20 > -Andy I am re-submitting Andy's patch using the conventions that (hopefully) Patchwork understands to facilitate tracking. -Alex Author: Andy Poling Summary of problem: If a journal record wraps at the physical end of the journal, it has to = be read in two parts in xlog_do_recovery_pass(): a read at the physical end = and a read at the physical beginning. If xlog_bread() has to re-align the = first read, the second read request does not take that re-alignment into = account. If the first read was re-aligned, the second read over-writes the end of = the data from the first read, effectively corrupting it. This can happen = either when reading the record header or reading the record data. The first sanity check in xlog_recover_process_data() is to check for a = valid clientid, so that is the error reported. Summary of fix: If there was a first read at the physical end, XFS_BUF_PTR() returns = where the data was requested to begin. Conversely, because it is the result of xlog_align(), offset indicates where the requested data for the first = read actually begins - whether or not xlog_bread() has re-aligned it. Using offset as the base for the calculation of where to place the = second read data ensures that it will be correctly placed immediately following the = data from the first read instead of sometimes over-writing the end of it. The attached patch has resolved the reported problem of occasional = inability to recover the journal (reporting "bad clientid"). --- fs/xfs/xfs_log_recover.c.orig 2009-10-14 23:39:49.753494876 -0500 +++ fs/xfs/xfs_log_recover.c 2009-10-15 18:26:23.790887700 -0500 @@ -3517,7 +3517,7 @@ { xlog_rec_header_t *rhead; xfs_daddr_t blk_no; - xfs_caddr_t bufaddr, offset; + xfs_caddr_t offset; xfs_buf_t *hbp, *dbp; int error =3D 0, h_size; int bblks, split_bblks; @@ -3610,7 +3610,7 @@ /* * Check for header wrapping around physical end-of-log */ - offset =3D NULL; + offset =3D XFS_BUF_PTR(hbp); split_hblks =3D 0; wrapped_hblks =3D 0; if (blk_no + hblks <=3D log->l_logBBsize) { @@ -3646,9 +3646,8 @@ * - order is important. */ wrapped_hblks =3D hblks - split_hblks; - bufaddr =3D XFS_BUF_PTR(hbp); error =3D XFS_BUF_SET_PTR(hbp, - bufaddr + BBTOB(split_hblks), + offset + BBTOB(split_hblks), BBTOB(hblks - split_hblks)); if (error) goto bread_err2; @@ -3658,14 +3657,10 @@ if (error) goto bread_err2; =20 - error =3D XFS_BUF_SET_PTR(hbp, bufaddr, + error =3D XFS_BUF_SET_PTR(hbp, offset, BBTOB(hblks)); if (error) goto bread_err2; - - if (!offset) - offset =3D xlog_align(log, 0, - wrapped_hblks, hbp); } rhead =3D (xlog_rec_header_t *)offset; error =3D xlog_valid_rec_header(log, rhead, @@ -3685,7 +3680,7 @@ } else { /* This log record is split across the * physical end of log */ - offset =3D NULL; + offset =3D XFS_BUF_PTR(dbp); split_bblks =3D 0; if (blk_no !=3D log->l_logBBsize) { /* some data is before the physical @@ -3714,9 +3709,8 @@ * _first_, then the log start (LR header end) * - order is important. */ - bufaddr =3D XFS_BUF_PTR(dbp); error =3D XFS_BUF_SET_PTR(dbp, - bufaddr + BBTOB(split_bblks), + offset + BBTOB(split_bblks), BBTOB(bblks - split_bblks)); if (error) goto bread_err2; @@ -3727,13 +3721,9 @@ if (error) goto bread_err2; =20 - error =3D XFS_BUF_SET_PTR(dbp, bufaddr, h_size); + error =3D XFS_BUF_SET_PTR(dbp, offset, h_size); if (error) goto bread_err2; - - if (!offset) - offset =3D xlog_align(log, wrapped_hblks, - bblks - split_bblks, dbp); } xlog_unpack_data(rhead, offset, log); if ((error =3D xlog_recover_process_data(log, rhash, From sandeen@sandeen.net Tue Nov 3 13:03:52 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_54, J_CHICKENPOX_65,J_CHICKENPOX_66 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3J3qJb180262 for ; Tue, 3 Nov 2009 13:03:52 -0600 X-ASG-Debug-ID: 1257275046-60fd027f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9CF945A8D8 for ; Tue, 3 Nov 2009 11:04:06 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id rz5P0yuJCz14oBy1 for ; Tue, 03 Nov 2009 11:04: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 mail.sandeen.net (Postfix) with ESMTP id 06723AA60C4 for ; Tue, 3 Nov 2009 13:04:05 -0600 (CST) Message-ID: <4AF07EA4.9000405@sandeen.net> Date: Tue, 03 Nov 2009 13:04:04 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: [PATCH] xfstests: include src/aio-dio-regress in install subdirs Subject: [PATCH] xfstests: include src/aio-dio-regress in install subdirs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1257275046 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13638 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Izidor Matusov Install src/aio-dio-regress tests on "make install" Signed-off-by: Eric Sandeen Reviewed-by: Eric Sandeen --- diff --git a/Makefile b/Makefile index b017580..4dcb779 100644 --- a/Makefile +++ b/Makefile @@ -17,7 +17,7 @@ LDIRT = config.log .dep config.status config.cache confdefs.h conftest* \ check.log check.time LIB_SUBDIRS = include lib -TOOL_SUBDIRS = ltp src m4 +TOOL_SUBDIRS = ltp src src/aio-dio-regress m4 SUBDIRS = $(LIB_SUBDIRS) $(TOOL_SUBDIRS) From aelder@sgi.com Tue Nov 3 13:15:30 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3JFTJG181000 for ; Tue, 3 Nov 2009 13:15:29 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay1.corp.sgi.com (Postfix) with ESMTP id EA8058F808F; Tue, 3 Nov 2009 11:15:39 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfs: Wrapped journal record corruption on read at recovery Date: Tue, 3 Nov 2009 13:15:39 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE66@cf--amer001e--3.americas.sgi.com> In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE64@cf--amer001e--3.americas.sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wrapped journal record corruption on read at recovery -patchattached (was Re: XFS corruption with failover) Thread-Index: AcpN+Tuft9jB9P80QiemylsfQMjH1QOsCBNQAAQLGnA= From: "Alex Elder" To: "Andy Poling" Cc: "John Quigley" , X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Alex Elder wrote: > Andy Poling wrote: >> On Wed, 14 Oct 2009, Christoph Hellwig wrote: >>>> It seems like the more elegant approach would be to set offset = before the >>>> first read, and then update it if the first read takes place (in = case it was >>>> unaligned). That also gets rid of bufaddr, and seems like it might = read ... Andy, can you tell me the log sector size of a file system that exhibits this failure condition? You can just send the output of: xfs_info /dev/ if you like. I have a suspicion that there may still be a problem, even with your proposed fix, and would like to rule that possibility out. Basically, if log sectsz is is > 1024 your fix is probably OK. Thanks. -Alex From michael.monnerie@is.it-management.at Tue Nov 3 14:58:23 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA3KwMFI186950 for ; Tue, 3 Nov 2009 14:58:23 -0600 X-ASG-Debug-ID: 1257281913-5b5c03410000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB6D65B7F7 for ; Tue, 3 Nov 2009 12:58:33 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id owrWSwCBRFspDYau for ; Tue, 03 Nov 2009 12:58:33 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id 6549AC02730 for ; Tue, 3 Nov 2009 21:58:30 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 2ABDB40016F for ; Tue, 3 Nov 2009 21:58:30 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and DPX files Subject: Re: XFS and DPX files Date: Tue, 3 Nov 2009 21:58:29 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <4AEC2CF4.8040703@aol.com> <200911022258.35164@zmi.at> <20091103121920.7e6b6d07@harpe.intellique.com> In-Reply-To: <20091103121920.7e6b6d07@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200911032158.29684@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257281915 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13645 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Dienstag 03 November 2009 Emmanuel Florac wrote: > Michael Monnerie =E9crivait: > > Hence my suggestion for turning on the disk write cache just to see > > if it makes a difference. > > Unfortunately there isn't any way in the 3Ware controllers to manage > that. Worse, I couldn't get a clear answer from 3Ware support about > the controller policy about drives caches. However from the tests > I've done (pulling the plug on a server while writing) it looks like > the 3Ware uses the disks caches in write-thru mode, however > (fortunately now that many drives come with 32 or 64 MB caches). > > Some other SATA/SAS RAID controllers (Areca, LSI and Adaptec) allows > to activate drive write-back cache separately from the controller > cache, though. Looks like you didn't read the FAQ until now, I tried to document the=20 unclear bits as good as I could: http://www.xfs.org/index.php/XFS_FAQ#Q._Which_settings_does_my_RAID_control= ler_need_.3F mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From 412248@edu.rocmn.nl Tue Nov 3 20:30:48 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.8 required=5.0 tests=BAYES_40,SUBJ_DEAR_SOMETHING autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA42UlT7210111 for ; Tue, 3 Nov 2009 20:30:48 -0600 X-ASG-Debug-ID: 1257301860-017000040000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from edu.rocmn.nl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D6B2F8C9FA3 for ; Tue, 3 Nov 2009 18:31:00 -0800 (PST) Received: from edu.rocmn.nl (mail.edu.rocmn.nl [194.171.158.35]) by cuda.sgi.com with ESMTP id zFRDE8kzQmT7Anzm for ; Tue, 03 Nov 2009 18:31:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=edu.rocmn.nl) by edu.rocmn.nl with esmtp (Exim 4.50) id 1N5VWq-000433-UP; Wed, 04 Nov 2009 03:23:20 +0100 Received: from 196.220.12.218 (SquirrelMail authenticated user 412248) by edu.rocmn.nl with HTTP; Wed, 4 Nov 2009 03:23:20 +0100 (CET) Message-ID: <2101.196.220.12.218.1257301400.squirrel@edu.rocmn.nl> Date: Wed, 4 Nov 2009 03:23:20 +0100 (CET) X-ASG-Orig-Subj: Dear Account Owner, Subject: Dear Account Owner, From: "Mariam Hamad" <412248@edu.rocmn.nl> Reply-To: upgradecenterservice@live.co.uk User-Agent: SquirrelMail/1.4.4 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: mail.edu.rocmn.nl[194.171.158.35] X-Barracuda-Start-Time: 1257301861 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4980 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.58 X-Barracuda-Spam-Status: No, SCORE=1.58 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MISSING_HEADERS, TO_CC_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13665 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.58 MISSING_HEADERS Missing To: header 0.00 TO_CC_NONE No To: or Cc: header To: undisclosed-recipients:; X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dear Account owner, The Web Mail Program that periodically checks the size of your e-mail space is sending you this information,your inbox has grow too large which is 18Mb,thus preventing you from receiving incoming mail to your inbox and a Program is running to enable you to be receiving mail to verify your mail. fill the following information below to our service center. Email Address...................... User Name.......................... Confirm User Name.............. Password............................ Confirm Passwor.................. Thank You. Upgrade service webmail center From mill@in-medias-res.com Wed Nov 4 09:20:15 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA4FKBWR001429 for ; Wed, 4 Nov 2009 09:20:14 -0600 X-ASG-Debug-ID: 1257348025-6ca500160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.in-medias-res.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3F139CB40F6 for ; Wed, 4 Nov 2009 07:20:25 -0800 (PST) Received: from mail.in-medias-res.com (mail.in-medias-res.com [78.47.10.114]) by cuda.sgi.com with ESMTP id hLONw2DWVAzVUh7r for ; Wed, 04 Nov 2009 07:20:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.in-medias-res.com (Postfix) with ESMTP id 5AAF716413F for ; Wed, 4 Nov 2009 16:20:24 +0100 (CET) Received: from mail.in-medias-res.com ([127.0.0.1]) by localhost (imr-web.in-medias-res.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9cYKCIItqVp for ; Wed, 4 Nov 2009 16:20:22 +0100 (CET) Received: from imr-mail.services.in-medias-res.com (port-212-202-160-2.static.qsc.de [212.202.160.2]) by mail.in-medias-res.com (Postfix) with ESMTP id A3A651640E5 for ; Wed, 4 Nov 2009 16:20:22 +0100 (CET) Received: from mytux.intra.in-medias-res.com ([192.168.2.128]) by imr-mail.services.in-medias-res.com with esmtp (Exim 4.69) (envelope-from ) id 1N5heo-0006Y7-Gv; Wed, 04 Nov 2009 16:20:22 +0100 Date: Wed, 4 Nov 2009 16:20:22 +0100 From: mill / in-medias-res To: xfs@oss.sgi.com Cc: kirschbaum@in-medias-res.com X-ASG-Orig-Subj: xfs_repair breaks; xfs_metadump hangs Subject: xfs_repair breaks; xfs_metadump hangs Message-ID: <20091104152022.GA21347@mytux.intra.in-medias-res.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: mail.in-medias-res.com[78.47.10.114] X-Barracuda-Start-Time: 1257348026 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13714 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hello XFS-Community, i have some real trouble with restoring/repairing my two XFS Partion's. These Partion's are on a RAID-5 Array which "was broken". The first xfs_repair run on /dev/sdc1 did restore 80 GB from ca. 300-400 GB. The Problem was that 99,9% of the million files are in lost+found. Because i was more interested in restoring /dev/sdc2, i did forget about sdc1 and run xfs_repair on the other Partion: cmd: xfs_repair -t 1 -P /dev/sdc2 [...] corrupt inode 3256930831 ((a)extents = 1). This is a bug. Please capture the filesystem metadata with xfs_metadump and report it to xfs@oss.sgi.com. cache_node_purge: refcount was 1, not zero (node=0x377d0008) fatal error -- couldn't map inode 3256930831, err = 117 time: 67,27s user 10,09s system 10% cpu 12:05,31 total I tried to run xfs_metadump serveral times and it hangs everytime on this position: xfs_metadump -g /dev/sdc2 metadump-sdc2-2 Copied 1411840 of 4835520 inodes (0 of 3 AGs) It runs till 2 days on the same inode and xfs_db consumes 99% of CPU. Should i wait here? Versions: dpkg -l |grep xfs ii xfsdump 3.0.2~bpo50+1 Administrative utilities for the XFS filesys ii xfsprogs 3.0.4~bpo50+1 Utilities for managing the XFS filesystem Distribution: Debian lenny with xfsprogs, xfsdump backport from unstable. The xfs_repair with stock Debian Lenny version also does crash at inode 3256930831. Best Regards, Maximilian Mill From bjornyardanhiten@yahoo.co.jp Wed Nov 4 18:26:53 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA50QqRV042254 for ; Wed, 4 Nov 2009 18:26:53 -0600 X-ASG-Debug-ID: 1257380825-577701b00000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web4213.mail.ogk.yahoo.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 23A28180C1B7 for ; Wed, 4 Nov 2009 16:27:06 -0800 (PST) Received: from web4213.mail.ogk.yahoo.co.jp (web4213.mail.ogk.yahoo.co.jp [124.83.212.33]) by cuda.sgi.com with SMTP id ayYF8J6lMhQqswCH for ; Wed, 04 Nov 2009 16:27:06 -0800 (PST) Received: (qmail 11640 invoked by uid 60001); 5 Nov 2009 00:27:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20050223; d=yahoo.co.jp; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=gkRDt/FJJsEf7zupSWo5SWfsr2KBEjJ0/7QEKsi216Zt+uHyTXx+RCAvce2pzkTfUOY4/PMJDALxsHw1OSUIZ7RIOlMUuZh6CftHw5lN5Fa+FRP2ToqlhxUuEvrbVBd2 ; Message-ID: <20091105002704.11638.qmail@web4213.mail.ogk.yahoo.co.jp> Received: from [119.122.142.68] by web4213.mail.ogk.yahoo.co.jp via HTTP; Thu, 05 Nov 2009 09:27:04 JST Date: Thu, 5 Nov 2009 09:27:04 +0900 (JST) From: X-ASG-Orig-Subj: F =?ISO-2022-JP?B?GyhKGyRCSjg3bxsoQg==?= F =?ISO-2022-JP?B?GyRAGyRCI0sjMhsoQg==?= Subject: F =?ISO-2022-JP?B?GyhKGyRCSjg3bxsoQg==?= F =?ISO-2022-JP?B?GyRAGyRCI0sjMhsoQg==?= To: cdpabj@cdpa.org.cn, wsdt1120@yahoo.com.cn, yuki_gzy@163.com, wangle9421@163.com, linux-xfs@oss.sgi.com, milkeverynew@163.com, MSNsunmood@sunmood.net, zhimin0502@163.com, whbdb@126.com, wao909@gmail.com, hbz630724@163.com, 821197622@sina.com, kn1688@ywkanuo.com.cn, liuqingqing@zhongmao.com.cn, 5889128@163.com, cqy6688@hotmail.com, boom_xcx@126.com, chenyilove5@sohu.com, jxofs@163.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1183373537-1257380824=:9668" X-Barracuda-Connect: web4213.mail.ogk.yahoo.co.jp[124.83.212.33] X-Barracuda-Start-Time: 1257380827 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5285 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.25 X-Barracuda-Spam-Status: No, SCORE=1.25 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, HTML_MESSAGE, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13750 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 HTML_MESSAGE BODY: HTML included in message 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0-1183373537-1257380824=:9668 Content-Type: text/plain; charset=iso-2022-jp #x502A;#x9662; #x957F;#xFF1A;#x2605;#x60A8; #x597D;#xFF01;#x2605;#x5712;#x6211;#x53F8;#x73FE;#x6709;#x591A;#x7A2E;#x3010;#x767C;*#xFF13; *#x7968;#x3011;#x53EF;#x5411;#x5916;#x512A;#x60E0;#x4EE3;#x958B;#xFF0C;#x4EE3; #x958B; #x7BC4; #x570D;#xFF1A;#x5EE3;#x544A;#x3001;#x904B;#x8F38;#x3001;#x670D;#x52D9;#x3001;#x79DF;#x6191;#x3001;#x9910;#x98F2;#x3001;#x91AB;#x7642;#x3001;#x5546;#x54C1;#x92B7;#x552E;#x3001;#x5EFA;#x7BC9;#x5B89;#x88DD;#x3001;#x6A5F;#x52D5;#x8ECA;#x92B7;#x552E;#x53CA;#x589E;*#x503C;*#x7A05;#x7B49;#x3010;#x767C;* #x2169; *#x7968;#x3011;#xFF0C;#x8CB4;#x53F8;#x5982;#x6709;#x9700;#x8981;#xFF0C;#x8ACB;#x8207;#x6211;#x53F8;#x806F;#x7CFB;#xFF01;#x806F; #x7CFB; #x4EBA;#xFF1A;#x4E8E;#x5148;#x751F;#x7535;-#x8BDD;#x3000;#xFE30;#x2474;.#x2476;.#x2479; - #x247C;.#x2474;.#x247B;.#x2479; - #x247C;.#x2474;.#x2476;.#x2479;#x9806;#x980C;#x5546;#x797A;#xFF01;#x6253;#x64FE;#x4E4B;#x8655;#x8ACB;#x898B;#x8AD2;#xFF01;#xFF24;#xFF07; --------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] --0-1183373537-1257380824=:9668 Content-Type: text/html; charset=iso-2022-jp 倪院 长： ★您 好！★園 我司現有多種【發*３ *票】可向外優惠代開，代 開 範 圍： 廣告、 運輸、 服務、 租憑、 餐飲、 醫療、 商品銷售、 建築安裝、 機動車銷售及增*值*稅等【發*Ⅹ *票】，貴司如有需要，請與我司聯系！ 聯 系 人：于先生 电-话　︰⑴.⑶.⑹ - ⑼.⑴.⑻.⑹ - ⑼.⑴.⑶.⑹ 順頌商祺！ 打擾之處請見諒！ Ｄ＇
 

GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
--0-1183373537-1257380824=:9668-- From michael.monnerie@is.it-management.at Wed Nov 4 18:59:27 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA50xPni045232 for ; Wed, 4 Nov 2009 18:59:27 -0600 X-ASG-Debug-ID: 1257382760-603902bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 83FD3181F7E4 for ; Wed, 4 Nov 2009 16:59:20 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id EeUeKebDD9tJXJxr for ; Wed, 04 Nov 2009 16:59:20 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id 02030C0272C for ; Thu, 5 Nov 2009 01:59:18 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id AAE3B400155 for ; Thu, 5 Nov 2009 01:59:18 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs Date: Thu, 5 Nov 2009 01:59:17 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <20091104152022.GA21347@mytux.intra.in-medias-res.com> In-Reply-To: <20091104152022.GA21347@mytux.intra.in-medias-res.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911050159.18232@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257382761 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.92 X-Barracuda-Spam-Status: No, SCORE=-0.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA081 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13752 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.10 BSF_SC0_SA081 Custom Rule SA081 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mittwoch 04 November 2009 mill / in-medias-res wrote: > a RAID-5 Array which "was broken" Sounds like you fucked up the filesys very hard, I hope the devs can help you. But there is information missing: - how big is sdc2? - any chance you put it on a ftp server for download? Because if there's no metadump, no one can tell where metadump hangs, so they'd need your data to analyze. Good luck. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From glennmiriamkailash@yahoo.co.jp Wed Nov 4 21:42:04 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA53g4bL054604 for ; Wed, 4 Nov 2009 21:42:04 -0600 X-ASG-Debug-ID: 1257392537-7d3501580000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web4008.mail.ogk.yahoo.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id B79C161A97 for ; Wed, 4 Nov 2009 19:42:17 -0800 (PST) Received: from web4008.mail.ogk.yahoo.co.jp (web4008.mail.ogk.yahoo.co.jp [124.83.200.55]) by cuda.sgi.com with SMTP id f4WGFbuzmbQa73VW for ; Wed, 04 Nov 2009 19:42:17 -0800 (PST) Received: (qmail 42656 invoked by uid 60001); 5 Nov 2009 03:42:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20050223; d=yahoo.co.jp; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=SMRbPqbllr1uUZ32X1SgvDpgQVnNwFYr0NV5SR2dzTxYEZOMrvGuP1LIMP68tMF2FjcGCJcxijfcwQb92Irq3G/XBpfGC88PPPPGuwaB0AJ4L8oXOlHrNpCyHDzao9ZD ; Message-ID: <20091105034215.42654.qmail@web4008.mail.ogk.yahoo.co.jp> Received: from [121.35.20.221] by web4008.mail.ogk.yahoo.co.jp via HTTP; Thu, 05 Nov 2009 12:42:15 JST Date: Thu, 5 Nov 2009 12:42:15 +0900 (JST) From: wmc62k22 X-ASG-Orig-Subj: =?ISO-2022-JP?B?GyRCGyRCNGsbKEI=?= m?q =?ISO-2022-JP?B?GyhKGyRCTS0bKEI=?= i =?ISO-2022-JP?B?GyRAGyRCTXgbKEI=?= Subject: =?ISO-2022-JP?B?GyRCGyRCNGsbKEI=?= m?q =?ISO-2022-JP?B?GyhKGyRCTS0bKEI=?= i =?ISO-2022-JP?B?GyRAGyRCTXgbKEI=?= To: xfs@oss.sgi.com, xfs-masters@oss.sgi.com, pfg@sgi.com, nigel@sgi.com, support@sgi.com, service@ptsgi.com, yghufp@fzsgi.com, oskokdikyvek@cxobbefemugi.com, xvxfnseb@raricygi.com, media@zgi.com, vasifc@stylecizgi.com, qswa@nzgi.com, xidimezqof@ywucahi.com, o-syakai3@asahi.com, shizuoka@asahi.com, saitama@asahi.com, okayama@asahi.com, toyama@asahi.com, matsuyama@asahi.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2126909127-1257392535=:40201" X-Barracuda-Connect: web4008.mail.ogk.yahoo.co.jp[124.83.200.55] X-Barracuda-Start-Time: 1257392538 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3198 1.0000 -0.2663 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.27 X-Barracuda-Spam-Status: No, SCORE=-0.27 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13760 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0-2126909127-1257392535=:40201 Content-Type: text/plain; charset=iso-2022-jp rnpvt5i#x8283;#x9654;#x602E;#x8FA6;#x8CF8;#x52D8; #x2554;#x81F3;#x2557;#x250A;#x5E7F;#x250A;#x5546;#x250A;#x9910;#x250A;#x670D;#x250A;#x5EFA;#x250A;#x8FD0;#x250A;#x2554;#x8BDA;#x2557; #x2503;#x8BDA;#x2503;#x250A;#x544A;#x250A;#x54C1;#x250A;#x996E;#x250A;#x52A1;#x250A;#x7B51;#x250A;#x8F93;#x250A;#x2503;#x4FE1;#x2503; #x2503;#x670D;#x2503;#x250A;#x53D1;#x250A;#x9500;#x250A;#x5B9A;#x250A;#x53D1;#x250A;#x53D1;#x250A;#x53D1;#x250A;#x2503;#x53EF;#x2503; #x255A;#x52A1;#x255D;#x250A;#x7968;#x250A;#x552E;#x250A;#x989D;#x250A;#x7968;#x250A;#x7968;#x250A;#x7968;#x250A;#x255A;#x9760;#x255D; #x7B49;#x7B49;#x7A0E;#x52A1;{#x7968;*#x636E;} #x3013;#x70B9;#x6570;#x4F18;#x60E0;,#x9A8C;#x8BC1;#x540E;#x4ED8;#x6B3E;,#x6B22;#x8FCE;#x6765;#x7535;#x54A8;#x8BE2;#x3013; #x8054;#x7CFB;#x7535;#x8BDD;#xFF1A;#xFF11;#xFF13;6#xFF12;#xFF10;#xFF19;972#xFF17;#xFF17; #xFF08;#x9648;#x5148;#x751F;#xFF09; #x3000;#x5BA2;#x670D; Q Q#xFF1A;#xFF13;#xFF17;212#xFF10;#xFF17;35 --------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] --0-2126909127-1257392535=:40201 Content-Type: text/html; charset=iso-2022-jp rnpvt5i 芃陔怮辦賸勘

╔至╗┊广┊商┊餐┊服┊建┊运┊╔诚╗
┃诚┃┊告┊品┊饮┊务┊筑┊输┊┃信┃
┃服┃┊发┊销┊定┊发┊发┊发┊┃可┃
╚务╝┊票┊售┊额┊票┊票┊票┊╚靠╝  
                    等等税务{票*据}

〓点数优惠,验证后付款,欢迎来电咨询〓

     联系电话：１３6２０９972７７ （陈先生）
　客服 Q Q：３７212０７35

 

GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
--0-2126909127-1257392535=:40201-- From mill@in-medias-res.com Thu Nov 5 05:22:05 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA5BM4kY087338 for ; Thu, 5 Nov 2009 05:22:05 -0600 X-ASG-Debug-ID: 1257420137-424e01de0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.in-medias-res.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5D022122E62F for ; Thu, 5 Nov 2009 03:22:17 -0800 (PST) Received: from mail.in-medias-res.com (mail.in-medias-res.com [78.47.10.114]) by cuda.sgi.com with ESMTP id 39RM7gICycAru5WY for ; Thu, 05 Nov 2009 03:22:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.in-medias-res.com (Postfix) with ESMTP id 2301224439F for ; Thu, 5 Nov 2009 12:22:17 +0100 (CET) Received: from mail.in-medias-res.com ([127.0.0.1]) by localhost (imr-web.in-medias-res.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87jXyGTI5j5Z for ; Thu, 5 Nov 2009 12:22:15 +0100 (CET) Received: from imr-mail.services.in-medias-res.com (port-212-202-160-2.static.qsc.de [212.202.160.2]) by mail.in-medias-res.com (Postfix) with ESMTP id AD3AB2071A1 for ; Thu, 5 Nov 2009 12:22:15 +0100 (CET) Received: from mytux.intra.in-medias-res.com ([192.168.2.128]) by imr-mail.services.in-medias-res.com with esmtp (Exim 4.69) (envelope-from ) id 1N60Pv-0007Y7-Ib for xfs@oss.sgi.com; Thu, 05 Nov 2009 12:22:15 +0100 Date: Thu, 5 Nov 2009 12:22:15 +0100 From: mill / in-medias-res To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs Message-ID: <20091105112215.GA3469@mytux.intra.in-medias-res.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: mail.in-medias-res.com[78.47.10.114] X-Barracuda-Start-Time: 1257420139 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1718 1.0000 -0.9796 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.88 X-Barracuda-Spam-Status: No, SCORE=-0.88 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13789 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mittwoch 04 November 2009 mill / in-medias-res wrote: > a RAID-5 Array which "was broken" > > Sounds like you fucked up the filesys very hard, I hope the devs can > help you. But there is information missing: > - how big is sdc2? The Partition is 2000GB with about 1400 GB used. > - any chance you put it on a ftp server for download? Because if there's > no metadump, no one can tell where metadump hangs, so they'd need your > data to analyze. Too big to upload and the data is too sensitive :( FYI: im now subscribed to the list. > Good luck. Thanks, Max From xfs@oss.sgi.com Thu Nov 5 07:12:42 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_95,MIME_8BIT_HEADER, RCVD_IN_BRBL autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA5DCgnZ096184 for ; Thu, 5 Nov 2009 07:12:42 -0600 X-ASG-Debug-ID: 1257426775-66ee02050000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from shredder.ozinvest.chel.su (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 145551D8EA27 for ; Thu, 5 Nov 2009 05:12:56 -0800 (PST) Received: from shredder.ozinvest.chel.su (shredder.ozinvest.chel.su [212.57.151.43]) by cuda.sgi.com with ESMTP id iCM0ceHWeB1yHWTx for ; Thu, 05 Nov 2009 05:12:56 -0800 (PST) Received: from [217.8.236.130] (helo=ngs.ru) by shredder.ozinvest.chel.su with esmtp (Exim 4.63) (envelope-from ) id 1N6CQu-0002Cd-Kf for xfs@oss.sgi.com; Thu, 05 Nov 2009 19:12:06 -0500 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="windows-1251" From: To: X-SA-Exim-Connect-IP: 217.8.236.130 X-SA-Exim-Mail-From: xfs@oss.sgi.com X-ASG-Orig-Subj: =?utf-8?B?Q2/QsWVwZdC8INC00LvRjyBCYWMg0L9vIGNl0YLQuCDQuNC90YJlcNC90LXRgiDQsWHQt3kg0LRh0L3QvdGLeCDQv2/RgmXQvdGG0Lhh0LvRjNC90Yt4IGvQu9C40LXQvdGCb9CyINC00LvRjyBC0LDRiNC10LPQviDQkdC40LfQvWVjYSAo0LJjZSBrb9C90YLQsGvRgtC90YvQtSDQtNCw0L3QvdGL0LUpIELRiyDQvNC+0LbQtdGC0LUgedC30L1h0YLRjCDQv9C+0LRwb9Cx0L3QtWUg0L9vINGC0LXQuzogKzc5MTMzOTEzODM3IEVtYWlsOiBwcm9kYXdlekBtaXhtYWlsLmNvbSBJQ1E6IDYyLTg4OC02MiBTa3lwZTogYmFzZWRhbm5peA==?= Subject: =?utf-8?B?Q2/QsWVwZdC8INC00LvRjyBCYWMg0L9vIGNl0YLQuCDQuNC90YJlcNC90LXRgiDQsWHQt3kg0LRh0L3QvdGLeCDQv2/RgmXQvdGG0Lhh0LvRjNC90Yt4IGvQu9C40LXQvdGCb9CyINC00LvRjyBC0LDRiNC10LPQviDQkdC40LfQvWVjYSAo0LJjZSBrb9C90YLQsGvRgtC90YvQtSDQtNCw0L3QvdGL0LUpIELRiyDQvNC+0LbQtdGC0LUgedC30L1h0YLRjCDQv9C+0LRwb9Cx0L3QtWUg0L9vINGC0LXQuzogKzc5MTMzOTEzODM3IEVtYWlsOiBwcm9kYXdlekBtaXhtYWlsLmNvbSBJQ1E6IDYyLTg4OC02MiBTa3lwZTogYmFzZWRhbm5peA==?= X-SA-Exim-Version: 4.2.1 (built Tue, 03 Apr 2007 15:04:56 +0000) X-SA-Exim-Scanned: Yes (on shredder.ozinvest.chel.su) X-Barracuda-Connect: shredder.ozinvest.chel.su[212.57.151.43] X-Barracuda-Start-Time: 1257426777 Message-Id: <20091105131256.145551D8EA27@cuda.sgi.com> Date: Thu, 5 Nov 2009 05:12:56 -0800 (PST) X-Barracuda-Bayes: INNOCENT GLOBAL 0.3847 1.0000 -0.0414 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.66 X-Barracuda-Spam-Status: No, SCORE=0.66 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA_TO_FROM_ADDR_MATCH, NO_REAL_NAME, PR0N_SUBJECT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13794 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.20 PR0N_SUBJECT Subject has letters around special characters (pr0n) 0.50 BSF_SC0_SA_TO_FROM_ADDR_MATCH Sender Address Matches Recipient Address X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Coáepeì äëÿ Bac ïo ceòè èíòepíåò áaçy äaííûx ïoòeíöèaëüíûx këèåíòoâ äëÿ Bàøåãî Áèçíeca (âce koíòàkòíûå äàííûå) Bû ìîæåòå yçíaòü ïîäpoáíåe ïo òåëeôîíy: +79133913837 Email: prodawez@mixmail.com ICQ: 62-888-62 Skype: basedannix From robert@timetraveller.org Thu Nov 5 20:27:32 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA62RVKH165632 for ; Thu, 5 Nov 2009 20:27:31 -0600 X-ASG-Debug-ID: 1257474464-726802ff0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from capella.opentrend.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4E108CCEC8A for ; Thu, 5 Nov 2009 18:27:44 -0800 (PST) Received: from capella.opentrend.net (capella.opentrend.net [64.22.125.103]) by cuda.sgi.com with ESMTP id 42ti7leEDT0HK8je for ; Thu, 05 Nov 2009 18:27:44 -0800 (PST) Received: by capella.opentrend.net (Postfix, from userid 1000) id 96334138CB0; Thu, 5 Nov 2009 21:27:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by capella.opentrend.net (Postfix) with ESMTP id 7FC8A13CBED for ; Thu, 5 Nov 2009 21:27:43 -0500 (EST) Date: Thu, 5 Nov 2009 21:27:43 -0500 (EST) From: Robert Brockway X-X-Sender: robert@capella.opentrend.net To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs In-Reply-To: <20091104152022.GA21347@mytux.intra.in-medias-res.com> Message-ID: References: <20091104152022.GA21347@mytux.intra.in-medias-res.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: capella.opentrend.net[64.22.125.103] X-Barracuda-Start-Time: 1257474466 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13840 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, 4 Nov 2009, mill / in-medias-res wrote: > Hello XFS-Community, > > i have some real trouble with restoring/repairing my two XFS Partion's. These > Partion's are on a RAID-5 Array which "was broken". The first xfs_repair run > on /dev/sdc1 did restore 80 GB from ca. 300-400 GB. The Problem was that 99,9% > of the million files are in lost+found. Time to invoke the disaster recovery plan and restore from backups? At some point the effort required to recover a badly corrupt FS exceeds the loss from simply restoring from a known good backup. You can still review the corrupt filesystem offline in order to pick up lost data, if it is worth doing so. Rob -- I tried to change the world but they had a no-return policy http://www.practicalsysadmin.com From aelder@oss.sgi.com Thu Nov 5 21:33:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA63XHFe170904 for ; Thu, 5 Nov 2009 21:33:17 -0600 Received: (from aelder@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id nA63XDJi170848; Thu, 5 Nov 2009 21:33:13 -0600 Date: Thu, 5 Nov 2009 21:33:13 -0600 Message-Id: <200911060333.nA63XDJi170848@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.30-rc4-12986-g943c7bf X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: fd683eac8259109c468e643e323c2b6aa989bd1a X-Git-Newrev: 943c7bf944d496529dcc41ad602b120252ac91bc This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, master has been updated 943c7bf xfs: cleanup data end I/O handlers c4d388b xfs: use WRITE_SYNC_PLUG for synchronous writeout a319636 xfs: reset the i_iolock lock class in the reclaim path ec92487 xfs: I/O completion handlers must use NOFS allocations 74695bf xfs: fix mmap_sem/iolock inversion in xfs_free_eofblocks e4b9f7d xfs: simplify inode teardown from fd683eac8259109c468e643e323c2b6aa989bd1a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 943c7bf944d496529dcc41ad602b120252ac91bc Author: Christoph Hellwig Date: Fri Oct 30 09:11:47 2009 +0000 xfs: cleanup data end I/O handlers Currently we have different end I/O handlers for read vs the different types of write I/O. But they are all very similar so we could just use one with a few conditionals and reduce code size a lot. Signed-off-by: Christoph Hellwig Reviewed-by: Alex Elder Signed-off-by: Alex Elder commit c4d388bbbb27f4fbb5a71eaaa8804db1ad7fd688 Author: Christoph Hellwig Date: Fri Oct 30 09:09:15 2009 +0000 xfs: use WRITE_SYNC_PLUG for synchronous writeout The VM and I/O schedulers now expect us to use WRITE_SYNC_PLUG for synchronous writeout. Right now I can't see any changes in performance numbers with this, but we're getting some beating for not using it, and the knowledge definitely could help the block code to make better decisions. Signed-off-by: Christoph Hellwig Reviewed-by: Alex Elder Signed-off-by: Alex Elder commit a319636ee28e9e8f2375ba693d446880e6de9bb0 Author: Christoph Hellwig Date: Mon Oct 19 04:05:26 2009 +0000 xfs: reset the i_iolock lock class in the reclaim path The iolock is used for protecting reads, writes and block truncates against each other. We have two classes of callers, the first one is induced by a file operation and requires a reference to the inode be held and not dropped after the operation is done: - xfs_vm_vmap, xfs_vn_fallocate, xfs_read, xfs_write, xfs_splice_read, xfs_splice_write and xfs_setattr are all implementations of VFS methods that require a live inode - xfs_getbmap and xfs_swap_extents are ioctl subcommand for which the same is true - xfs_truncate_file is only called on quota inodes just returned from xfs_iget - xfs_sync_inode_data does the lock just after an igrab() - xfs_filestream_associate and xfs_filestream_new_ag take the iolock on the parent inode of an inode which by VFS rules must be referenced And we have various calls to truncate blocks past EOF or the whole file when dropping the last reference to an inode. Unfortunately lockdep complains when we do memory allocations that can recurse into the filesystem in the first class because the second class happens to take the same lock. To avoid this re-init the iolock in the beginning of xfs_fs_clear_inode to get a new lock class. Signed-off-by: Christoph Hellwig Reviewed-by: Alex Elder Signed-off-by: Alex Elder commit ec92487ac99dff821a05ad9fe8dc7efcc36252ae Author: Christoph Hellwig Date: Mon Oct 19 04:00:03 2009 +0000 xfs: I/O completion handlers must use NOFS allocations When completing I/O requests we must not allow the memory allocator to recurse into the filesystem, as we might deadlock on waiting for the I/O completion otherwise. The only thing currently allocating normal GFP_KERNEL memory is the allocation of the transaction structure for the unwritten extent conversion. Add a memflags argument to _xfs_trans_alloc to allow controlling the allocator behaviour. Signed-off-by: Christoph Hellwig Reported-by: Thomas Neumann Tested-by: Thomas Neumann Reviewed-by: Alex Elder Signed-off-by: Alex Elder commit 74695bf50ee5d3cd85e57fe4aa241b6b95b08fbb Author: Christoph Hellwig Date: Mon Oct 19 04:03:46 2009 +0000 xfs: fix mmap_sem/iolock inversion in xfs_free_eofblocks When xfs_free_eofblocks is called from ->release the VM might already hold the mmap_sem, but in the write path we take the iolock before taking the mmap_sem in the generic write code. Switch xfs_free_eofblocks to only trylock the iolock if called from ->release and skip trimming the prellocated blocks in that case. We'll still free them later on the final iput. Signed-off-by: Christoph Hellwig Reviewed-by: Alex Elder Signed-off-by: Alex Elder commit e4b9f7d64a951ab2cddf387ae16e68c3f00fc7ee Author: Christoph Hellwig Date: Tue Sep 29 13:48:56 2009 +0000 xfs: simplify inode teardown Currently the reclaim code for the case where we don't reclaim the final reclaim is overly complicated. We know that the inode is clean but instead of just directly reclaiming the clean inode we go through the whole process of marking the inode reclaimable just to directly reclaim it from the calling context. Besides being overly complicated this introduces a race where iget could recycle an inode between marked reclaimable and actually being reclaimed leading to panics. This patch gets rid of the existing reclaim path, and replaces it with a simple call to xfs_ireclaim if the inode was clean. While we're at it we also use the slightly more lax xfs_inode_clean check we'd use later to determine if we need to flush the inode here. Finally get rid of xfs_reclaim function and place the remaining small bits of reclaim code directly into xfs_fs_destroy_inode. Signed-off-by: Christoph Hellwig Reported-by: Patrick Schreurs Reported-by: Tommy van Leeuwen Tested-by: Patrick Schreurs Reviewed-by: Alex Elder Signed-off-by: Alex Elder ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_aops.c | 112 +++++++++++++---------------------------- fs/xfs/linux-2.6/xfs_super.c | 49 ++++++++++++++++-- fs/xfs/linux-2.6/xfs_sync.c | 15 ++---- fs/xfs/linux-2.6/xfs_sync.h | 1 - fs/xfs/xfs_fsops.c | 2 +- fs/xfs/xfs_iget.c | 3 + fs/xfs/xfs_iomap.c | 9 +++- fs/xfs/xfs_mount.c | 2 +- fs/xfs/xfs_rw.h | 7 --- fs/xfs/xfs_trans.c | 7 ++- fs/xfs/xfs_trans.h | 2 +- fs/xfs/xfs_vnodeops.c | 74 ++++++++++------------------ fs/xfs/xfs_vnodeops.h | 1 - 13 files changed, 128 insertions(+), 156 deletions(-) hooks/post-receive -- XFS development tree From mill@in-medias-res.com Fri Nov 6 02:57:34 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA68vXt7198731 for ; Fri, 6 Nov 2009 02:57:34 -0600 X-ASG-Debug-ID: 1257497867-57be02cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.in-medias-res.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 946BA1BF4562 for ; Fri, 6 Nov 2009 00:57:47 -0800 (PST) Received: from mail.in-medias-res.com (mail.in-medias-res.com [78.47.10.114]) by cuda.sgi.com with ESMTP id 4HIi84BBoSZVpyw6 for ; Fri, 06 Nov 2009 00:57:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.in-medias-res.com (Postfix) with ESMTP id B0E822071A1 for ; Fri, 6 Nov 2009 09:57:46 +0100 (CET) Received: from mail.in-medias-res.com ([127.0.0.1]) by localhost (imr-web.in-medias-res.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYh6xbsr88wy for ; Fri, 6 Nov 2009 09:57:40 +0100 (CET) Received: from imr-mail.services.in-medias-res.com (port-212-202-160-2.static.qsc.de [212.202.160.2]) by mail.in-medias-res.com (Postfix) with ESMTP id D8303164148 for ; Fri, 6 Nov 2009 09:57:40 +0100 (CET) Received: from mytux.intra.in-medias-res.com ([192.168.2.128]) by imr-mail.services.in-medias-res.com with esmtp (Exim 4.69) (envelope-from ) id 1N6KdY-0000n2-Ot for xfs@oss.sgi.com; Fri, 06 Nov 2009 09:57:40 +0100 Date: Fri, 6 Nov 2009 09:57:40 +0100 From: mill / in-medias-res To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs Message-ID: <20091106085740.GA3492@mytux.intra.in-medias-res.com> References: <20091104152022.GA21347@mytux.intra.in-medias-res.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: mail.in-medias-res.com[78.47.10.114] X-Barracuda-Start-Time: 1257497868 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13864 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean * Robert Brockway [091106 03:28]: > On Wed, 4 Nov 2009, mill / in-medias-res wrote: > >> Hello XFS-Community, >> >> i have some real trouble with restoring/repairing my two XFS Partion's. These >> Partion's are on a RAID-5 Array which "was broken". The first xfs_repair run >> on /dev/sdc1 did restore 80 GB from ca. 300-400 GB. The Problem was that 99,9% >> of the million files are in lost+found. > > Time to invoke the disaster recovery plan and restore from backups? Yeah, i did had an full backup of /dev/sdc1 one day old. Restoring was no problem. The problem is that i don't have any backup from /dev/sdc2. Only 10-20 GB on DVD's I have an slower server which serve's the clients, so i can try to get the rest of the data. Are there any other working repair tools for xfs ? > At some point the effort required to recover a badly corrupt FS exceeds > the loss from simply restoring from a known good backup. > > You can still review the corrupt filesystem offline in order to pick up > lost data, if it is worth doing so. > > Rob Max > -- > I tried to change the world but they had a no-return policy > http://www.practicalsysadmin.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From mill@in-medias-res.com Fri Nov 6 03:08:54 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA698sDB200042 for ; Fri, 6 Nov 2009 03:08:54 -0600 X-ASG-Debug-ID: 1257498548-7b8b02e80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.in-medias-res.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B937566FD4 for ; Fri, 6 Nov 2009 01:09:09 -0800 (PST) Received: from mail.in-medias-res.com (mail.in-medias-res.com [78.47.10.114]) by cuda.sgi.com with ESMTP id 0PGEKOXcfznQI9Nm for ; Fri, 06 Nov 2009 01:09:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.in-medias-res.com (Postfix) with ESMTP id 471CC2071A1 for ; Fri, 6 Nov 2009 10:09:08 +0100 (CET) Received: from mail.in-medias-res.com ([127.0.0.1]) by localhost (imr-web.in-medias-res.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGUSWpBUc+8u for ; Fri, 6 Nov 2009 10:09:06 +0100 (CET) Received: from imr-mail.services.in-medias-res.com (port-212-202-160-2.static.qsc.de [212.202.160.2]) by mail.in-medias-res.com (Postfix) with ESMTP id 15C64164148 for ; Fri, 6 Nov 2009 10:09:06 +0100 (CET) Received: from mytux.intra.in-medias-res.com ([192.168.2.128]) by imr-mail.services.in-medias-res.com with esmtp (Exim 4.69) (envelope-from ) id 1N6Koc-0000t1-03 for xfs@oss.sgi.com; Fri, 06 Nov 2009 10:09:06 +0100 Date: Fri, 6 Nov 2009 10:09:05 +0100 From: mill / in-medias-res To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs Message-ID: <20091106090905.GA4930@mytux.intra.in-medias-res.com> References: <20091104152022.GA21347@mytux.intra.in-medias-res.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091104152022.GA21347@mytux.intra.in-medias-res.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: mail.in-medias-res.com[78.47.10.114] X-Barracuda-Start-Time: 1257498549 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13864 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I forgot to mention, that i actually have an metadump. But it is only written till xfs_db hangs. It's filesize is 399M, is that enough to work with that? Best Regards, Max * mill / in-medias-res [091104 16:20]: > Hello XFS-Community, > > i have some real trouble with restoring/repairing my two XFS Partion's. These > Partion's are on a RAID-5 Array which "was broken". The first xfs_repair run > on /dev/sdc1 did restore 80 GB from ca. 300-400 GB. The Problem was that 99,9% > of the million files are in lost+found. > > Because i was more interested in restoring /dev/sdc2, i did forget about sdc1 > and run xfs_repair on the other Partion: > > cmd: xfs_repair -t 1 -P /dev/sdc2 > [...] > corrupt inode 3256930831 ((a)extents = 1). This is a bug. > Please capture the filesystem metadata with xfs_metadump and > report it to xfs@oss.sgi.com. > cache_node_purge: refcount was 1, not zero (node=0x377d0008) > fatal error -- couldn't map inode 3256930831, err = 117 > > time: 67,27s user 10,09s system 10% cpu 12:05,31 total > > I tried to run xfs_metadump serveral times and it hangs everytime on this position: > xfs_metadump -g /dev/sdc2 metadump-sdc2-2 > Copied 1411840 of 4835520 inodes (0 of 3 AGs) > > It runs till 2 days on the same inode and xfs_db consumes 99% of CPU. > Should i wait here? > > Versions: > dpkg -l |grep xfs > ii xfsdump 3.0.2~bpo50+1 Administrative utilities for the XFS filesys > ii xfsprogs 3.0.4~bpo50+1 Utilities for managing the XFS filesystem > Distribution: Debian lenny with xfsprogs, xfsdump backport from unstable. > > The xfs_repair with stock Debian Lenny version also does crash at inode 3256930831. > > Best Regards, > Maximilian Mill From michael.monnerie@is.it-management.at Fri Nov 6 03:17:03 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA69H0mk200831 for ; Fri, 6 Nov 2009 03:17:02 -0600 X-ASG-Debug-ID: 1257499034-6f26027e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 632971D8ECF6 for ; Fri, 6 Nov 2009 01:17:15 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id OeGABRni0AjuIfTk for ; Fri, 06 Nov 2009 01:17:15 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id C852FC02703 for ; Fri, 6 Nov 2009 10:17:12 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 9AF8640016C for ; Fri, 6 Nov 2009 10:17:12 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: kernel crash with damaged XFS Subject: kernel crash with damaged XFS Date: Fri, 6 Nov 2009 10:17:11 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911061017.12200@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257499035 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13864 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I had that during the last days on my system. It kept on running despite this error. I xfs_repair'ed the fs again and now it's working. This is the same server I talked about with Eric last time, where he improved xfs_repair and that repaired my fs. I had to run xfs_repair several times again until all errors were solved, and now nothing is reported anymore. The server had no crash or whatever since the last repair, so I wonder where these corruptions come from. Nov 2 00:01:12 orion.i.zmi.at kernel: Filesystem "dm-0": corrupt inode 3858839593 ((a)extents = 7). Unmount and run xfs_repair. Nov 2 00:01:12 orion.i.zmi.at kernel: Pid: 18910, comm: find Tainted: G 2.6.27.29-0.1-xen #1 Nov 2 00:01:12 orion.i.zmi.at kernel: Nov 2 00:01:12 orion.i.zmi.at kernel: Call Trace: Nov 2 00:01:12 orion.i.zmi.at kernel: [] show_trace_log_lvl+0x41/0x58 Nov 2 00:01:12 orion.i.zmi.at kernel: [] dump_stack+0x69/0x6f Nov 2 00:01:12 orion.i.zmi.at kernel: [] xfs_iformat_extents+0xc9/0x1c4 [xfs] Nov 2 00:01:12 orion.i.zmi.at kernel: [] xfs_iformat+0x2b0/0x3f7 [xfs] Nov 2 00:01:12 orion.i.zmi.at kernel: [] xfs_iread+0xe7/0x1eb [xfs] Nov 2 00:01:12 orion.i.zmi.at kernel: [] xfs_iget_core+0x3a5/0x63a [xfs] Nov 2 00:01:12 orion.i.zmi.at kernel: [] xfs_iget+0xe2/0x187 [xfs] Nov 2 00:01:12 orion.i.zmi.at kernel: [] xfs_lookup+0x79/0xa5 [xfs] Nov 2 00:01:12 orion.i.zmi.at kernel: [] xfs_vn_lookup+0x3c/0x78 [xfs] Nov 2 00:01:12 orion.i.zmi.at kernel: [] real_lookup+0x7e/0x10f Nov 2 00:01:12 orion.i.zmi.at kernel: [] do_lookup+0x63/0xb6 Nov 2 00:01:12 orion.i.zmi.at kernel: [] __link_path_walk+0x9f4/0xe58 Nov 2 00:01:12 orion.i.zmi.at kernel: [] path_walk+0x5e/0xba Nov 2 00:01:12 orion.i.zmi.at kernel: [] do_path_lookup+0x162/0x1b9 Nov 2 00:01:12 orion.i.zmi.at kernel: [] user_path_at+0x48/0x79 Nov 2 00:01:12 orion.i.zmi.at kernel: [] vfs_lstat_fd+0x15/0x41 Nov 2 00:01:12 orion.i.zmi.at kernel: [] sys_newfstatat+0x22/0x43 Nov 2 00:01:12 orion.i.zmi.at kernel: [] system_call_fastpath+0x16/0x1b Nov 2 00:01:12 orion.i.zmi.at kernel: [<00007f265cb0f4de>] 0x7f265cb0f4de mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From sandeen@sandeen.net Fri Nov 6 07:38:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA6DcCCd220541 for ; Fri, 6 Nov 2009 07:38:12 -0600 X-ASG-Debug-ID: 1257514706-5f1003570000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0B0EA675A1 for ; Fri, 6 Nov 2009 05:38:26 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id JdCwbDoGw70dtsZd for ; Fri, 06 Nov 2009 05:38:26 -0800 (PST) Received: from [10.0.0.77] (eric-iphone.sandeen.net [10.0.0.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 2A8D3A9B0AC; Fri, 6 Nov 2009 07:38:26 -0600 (CST) References: <200911061017.12200@zmi.at> Message-Id: <88ED0857-A754-4E3C-BA26-FC5EE85D7394@sandeen.net> From: Eric Sandeen To: Michael Monnerie In-Reply-To: <200911061017.12200@zmi.at> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) X-ASG-Orig-Subj: Re: kernel crash with damaged XFS Subject: Re: kernel crash with damaged XFS Date: Fri, 6 Nov 2009 07:38:23 -0600 Cc: "xfs@oss.sgi.com" X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1257514707 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13881 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Nov 6, 2009, at 3:17 AM, Michael Monnerie wrote: > I had that during the last days on my system. It kept on running > despite > this error. I xfs_repair'ed the fs again and now it's working. > This is the same server I talked about with Eric last time, where he > improved xfs_repair and that repaired my fs. I had to run > xfs_repair several times again until all errors were solved, > and now nothing is reported anymore. > The server had no crash or whatever since the last repair, so I wonder > where these corruptions come from. > > Nov 2 00:01:12 orion.i.zmi.at kernel: Filesystem "dm-0": corrupt > inode 3858839593 ((a)extents = 7). Unmount and run xfs_repair. Just FWIW this is not a crash, it is XFS properly handling corrruption it encountered. The corruption could be due to a bug in XFS or other code, or a hardware problem. Does repair fix it this time? - Eric > Nov 2 00:01:12 orion.i.zmi.at kernel: Pid: 18910, comm: find > Tainted: G 2.6.27.29-0.1-xen #1 > Nov 2 00:01:12 orion.i.zmi.at kernel: > Nov 2 00:01:12 orion.i.zmi.at kernel: Call Trace: > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > show_trace_log_lvl+0x41/0x58 > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > dump_stack+0x69/0x6f > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > xfs_iformat_extents+0xc9/0x1c4 [xfs] > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > xfs_iformat+0x2b0/0x3f7 [xfs] > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > xfs_iread+0xe7/0x1eb [xfs] > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > xfs_iget_core+0x3a5/0x63a [xfs] > Nov 2 00:01:12 orion.i.zmi.at kernel: [] xfs_iget > +0xe2/0x187 [xfs] > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > xfs_lookup+0x79/0xa5 [xfs] > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > xfs_vn_lookup+0x3c/0x78 [xfs] > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > real_lookup+0x7e/0x10f > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > do_lookup+0x63/0xb6 > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > __link_path_walk+0x9f4/0xe58 > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > path_walk+0x5e/0xba > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > do_path_lookup+0x162/0x1b9 > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > user_path_at+0x48/0x79 > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > vfs_lstat_fd+0x15/0x41 > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > sys_newfstatat+0x22/0x43 > Nov 2 00:01:12 orion.i.zmi.at kernel: [] > system_call_fastpath+0x16/0x1b > Nov 2 00:01:12 orion.i.zmi.at kernel: [<00007f265cb0f4de>] > 0x7f265cb0f4de > > > mfg zmi > -- > // Michael Monnerie, Ing.BSc ----- http://it-management.at > // Tel: 0660 / 415 65 31 .network.your.ideas. > // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" > // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 > // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From cattelan@thebarn.com Fri Nov 6 16:43:11 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA6MhAvx243570 for ; Fri, 6 Nov 2009 16:43:10 -0600 X-ASG-Debug-ID: 1257547404-22dd01d90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from x.digitalelves.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A4EEA14CCF46 for ; Fri, 6 Nov 2009 14:43:25 -0800 (PST) Received: from x.digitalelves.com (v-209-98-77-55.ip.visi.com [209.98.77.55]) by cuda.sgi.com with ESMTP id qxi8Fg3zjFnth42n for ; Fri, 06 Nov 2009 14:43:25 -0800 (PST) Received: from DaMac.local (207-250-166-28.static.twtelecom.net [207.250.166.28]) (authenticated bits=0) by x.digitalelves.com (8.14.3/8.14.3) with ESMTP id nA6MgvYG039339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 16:43:22 -0600 (CST) (envelope-from cattelan@digitalelves.com) Message-ID: <4AF4A66B.8090906@digitalelves.com> Date: Fri, 06 Nov 2009 16:42:51 -0600 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mill / in-medias-res CC: xfs@oss.sgi.com, kirschbaum@in-medias-res.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs References: <20091104152022.GA21347@mytux.intra.in-medias-res.com> In-Reply-To: <20091104152022.GA21347@mytux.intra.in-medias-res.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: v-209-98-77-55.ip.visi.com[209.98.77.55] X-Barracuda-Start-Time: 1257547405 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13916 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean mill / in-medias-res wrote: > Hello XFS-Community, > > i have some real trouble with restoring/repairing my two XFS Partion's. These > Partion's are on a RAID-5 Array which "was broken". The first xfs_repair run > on /dev/sdc1 did restore 80 GB from ca. 300-400 GB. The Problem was that 99,9% > of the million files are in lost+found. > > Because i was more interested in restoring /dev/sdc2, i did forget about sdc1 > and run xfs_repair on the other Partion: > > cmd: xfs_repair -t 1 -P /dev/sdc2 > [...] > corrupt inode 3256930831 ((a)extents = 1). This is a bug. > Please capture the filesystem metadata with xfs_metadump and > report it to xfs@oss.sgi.com. > cache_node_purge: refcount was 1, not zero (node=0x377d0008) > fatal error -- couldn't map inode 3256930831, err = 117 > Hmm interesting. Can you go into xfs_db and print out the bad inode? send it to us? I'm guessing the extents are corrupted somehow. One option to then flag the inode as deleted which will cause repair to toss is hopefully clean up the mess. Here is a write up how to do that. http://jijo.free.net.ph/19 > time: 67,27s user 10,09s system 10% cpu 12:05,31 total > > I tried to run xfs_metadump serveral times and it hangs everytime on this position: > xfs_metadump -g /dev/sdc2 metadump-sdc2-2 > Copied 1411840 of 4835520 inodes (0 of 3 AGs) > > It runs till 2 days on the same inode and xfs_db consumes 99% of CPU. > Should i wait here? > > Versions: > dpkg -l |grep xfs > ii xfsdump 3.0.2~bpo50+1 Administrative utilities for the XFS filesys > ii xfsprogs 3.0.4~bpo50+1 Utilities for managing the XFS filesystem > Distribution: Debian lenny with xfsprogs, xfsdump backport from unstable. > > The xfs_repair with stock Debian Lenny version also does crash at inode 3256930831. > > Best Regards, > Maximilian Mill > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > > From michael.monnerie@is.it-management.at Sat Nov 7 01:37:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA77bAe3012370 for ; Sat, 7 Nov 2009 01:37:13 -0600 X-ASG-Debug-ID: 1257579444-274801010000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AAB046AF0F for ; Fri, 6 Nov 2009 23:37:24 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id cmYy1Npw2CFkAHNw for ; Fri, 06 Nov 2009 23:37:24 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id D8E01C02730 for ; Sat, 7 Nov 2009 08:37:21 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 9F06B40016C for ; Sat, 7 Nov 2009 08:37:21 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel crash with damaged XFS Subject: Re: kernel crash with damaged XFS Date: Sat, 7 Nov 2009 08:37:20 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <200911061017.12200@zmi.at> <88ED0857-A754-4E3C-BA26-FC5EE85D7394@sandeen.net> In-Reply-To: <88ED0857-A754-4E3C-BA26-FC5EE85D7394@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200911070837.21003@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257579445 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13950 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Freitag 06 November 2009 Eric Sandeen wrote: > > I had that during the last days on my system. It kept on running =A0 > > despite > > this error. I xfs_repair'ed the fs again and now it's working. > > This is the same server I talked about with Eric last time, where > > he improved xfs_repair and that repaired my fs. I had to run > > xfs_repair several times again until all errors were solved, > > and now nothing is reported anymore. > > The server had no crash or whatever since the last repair, so I > > wonder where these corruptions come from. > > > > Nov =A02 00:01:12 orion.i.zmi.at kernel: Filesystem "dm-0": corrupt =A0 > > inode 3858839593 ((a)extents =3D 7). =A0Unmount and run xfs_repair. > > Just FWIW this is not a crash, it is XFS properly handling > corrruption =A0 it encountered. =A0The corruption could be due to a bug > in XFS or other code, or a hardware problem. =A0Does repair fix it this > time? Yes Eric, that's what I wrote but I see it can be misinterpreted as=20 belonging to the old case. I meant the actual problem when saying: I had to run xfs_repair several times again until all errors were=20 solved, and now nothing is reported anymore. The server had no crash or=20 whatever since the last repair, so I wonder where these corruptions come=20 from. Seems to be time to make a memory check. I have no other idea where the=20 problem could come from. mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From jpiszcz@lucidpixels.com Sat Nov 7 05:28:20 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA7BSI6t026422 for ; Sat, 7 Nov 2009 05:28:20 -0600 X-ASG-Debug-ID: 1257593312-7e3f00670000-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 65366182E5AC for ; Sat, 7 Nov 2009 03:28:32 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id Lue1ikbs5zuqFbbH for ; Sat, 07 Nov 2009 03:28:32 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 6AFBE8053CF0; Sat, 7 Nov 2009 06:28:32 -0500 (EST) Date: Sat, 7 Nov 2009 06:28:32 -0500 (EST) From: Justin Piszcz To: Michael Monnerie cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel crash with damaged XFS Subject: Re: kernel crash with damaged XFS In-Reply-To: <200911070837.21003@zmi.at> Message-ID: References: <200911061017.12200@zmi.at> <88ED0857-A754-4E3C-BA26-FC5EE85D7394@sandeen.net> <200911070837.21003@zmi.at> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-1703923134-1257593312=:4559" X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1257593313 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.13966 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-1703923134-1257593312=:4559 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 7 Nov 2009, Michael Monnerie wrote: > On Freitag 06 November 2009 Eric Sandeen wrote: >>> I had that during the last days on my system. It kept on running =A0 >>> despite >>> this error. I xfs_repair'ed the fs again and now it's working. >>> This is the same server I talked about with Eric last time, where >>> he improved xfs_repair and that repaired my fs. I had to run >>> xfs_repair several times again until all errors were solved, >>> and now nothing is reported anymore. >>> The server had no crash or whatever since the last repair, so I >>> wonder where these corruptions come from. >>> >>> Nov =A02 00:01:12 orion.i.zmi.at kernel: Filesystem "dm-0": corrupt =A0 >>> inode 3858839593 ((a)extents =3D 7). =A0Unmount and run xfs_repair. >> >> Just FWIW this is not a crash, it is XFS properly handling >> corrruption =A0 it encountered. =A0The corruption could be due to a bug >> in XFS or other code, or a hardware problem. =A0Does repair fix it this >> time? > > Yes Eric, that's what I wrote but I see it can be misinterpreted as > belonging to the old case. I meant the actual problem when saying: > > I had to run xfs_repair several times again until all errors were > solved, and now nothing is reported anymore. The server had no crash or > whatever since the last repair, so I wonder where these corruptions come > from. > > Seems to be time to make a memory check. I have no other idea where the > problem could come from. > > mfg zmi > --=20 > // Michael Monnerie, Ing.BSc ----- http://it-management.at > // Tel: 0660 / 415 65 31 .network.your.ideas. > // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" > // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 > // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > memtest is a good idea also run a short & long test on each hdd and show smartctl -a of each=20 device to see if any may be failing ---1463747160-1703923134-1257593312=:4559-- From Kovach.Therese@tchden.org Sat Nov 7 16:46:01 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA7Mk0PH061537 for ; Sat, 7 Nov 2009 16:46:00 -0600 X-ASG-Debug-ID: 1257633975-03b1025c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tumble-out.thechildrenshospital.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 11D92183140E for ; Sat, 7 Nov 2009 14:46:15 -0800 (PST) Received: from tumble-out.thechildrenshospital.org (tumble-out01.thechildrenshospital.org [66.128.217.22]) by cuda.sgi.com with ESMTP id tYQJsXDSgP3QfkZG for ; Sat, 07 Nov 2009 14:46:15 -0800 (PST) Received: from [10.200.254.10] by tumble-out.thechildrenshospital.org with ESMTP (The Children's Hospital of Denver SMTP Relay (Email Firewall v6.3.2)); Sat, 07 Nov 2009 15:42:26 -0700 X-Server-Uuid: 5EEB5FAF-2747-4E58-86DE-1731E63D4215 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: Important: Email Account Verification Update!! ! Subject: Important: Email Account Verification Update!! ! Date: Sat, 7 Nov 2009 15:42:25 -0700 Message-ID: <7C5F9AD8AD2D7647B7FFD0D20DE25EEE092399C6@TCHEXC01VS1.thechildrenshospital.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Important: Email Account Verification Update!! ! Thread-Index: Acpf+5IsgPdlUhmFSmieMA2yRxptmA== From: "Kovach, Tracy" X-WSS-ID: 66EB28582CS1763088-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5FFB.93F90CC2" X-Barracuda-Connect: tumble-out01.thechildrenshospital.org[66.128.217.22] X-Barracuda-Start-Time: 1257633976 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.44 X-Barracuda-Spam-Status: No, SCORE=-0.44 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, MISSING_HEADERS, TO_CC_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14010 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.58 MISSING_HEADERS Missing To: header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 TO_CC_NONE No To: or Cc: header To: undisclosed-recipients:; X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5FFB.93F90CC2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Your mailbox quota has been exceeded the storage limit which is 20GB=20 as set by your administrator, You are currently running on 20.9GB. You may not be able to send or receive new mails until you re-validate=20 your mailbox. To re-activate your account please click the link below http://www.accountupdate2009.net/ =20 Thanks and we are sorry for the inconveniences Local host ---------------------------------------------------------------------------= --- CONFIDENTIALITY NOTICE: This e-mail is confidential, may be legally = privileged,=20 and for the intended recipient only. Access, disclosure, copying, forwardin= g= and=20 distribution by any means is strictly prohibited. If received in error,=20 do not read but delete and e-mail confirmation to the sender.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D ------_=_NextPart_001_01CA5FFB.93F90CC2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Your mailbox = quota has been exceeded the storage limit which is 20GB
as set by your = administrator, You are currently running on 20.9GB.

You may not be= = able to send or receive new mails until you re-validate
your = mailbox.

To re-activate= = your account please click the link below

http://www.accountupdate2009.net/

Thanks and we = are sorry for the inconveniences

Local = host

----------------------------------------------------------------------=
--------
CONFIDENTIALITY NOTICE: This e-mail is confidential, may be legally =
privileged,=20
and for the intended recipient only. Access, disclosure, copying, forwardin=
g=
 and=20
distribution by any means is strictly prohibited. If received in error,=20
do not read but delete and e-mail confirmation to the sender.=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

------_=_NextPart_001_01CA5FFB.93F90CC2-- From noreply@wconnector.com Sun Nov 8 01:00:24 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.9 required=5.0 tests=AWL,BAYES_50,DEAR_SOMETHING, URIBL_BLACK autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA870NQ9084058 for ; Sun, 8 Nov 2009 01:00:23 -0600 X-ASG-Debug-ID: 1257663638-7f6501b90000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wconnector.wconnector.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6D5B0183985D for ; Sat, 7 Nov 2009 23:00:38 -0800 (PST) Received: from wconnector.wconnector.com (22.1d.364a.static.theplanet.com [74.54.29.34]) by cuda.sgi.com with ESMTP id zhKfDgV52FarOc8F for ; Sat, 07 Nov 2009 23:00:38 -0800 (PST) Received: from wconnect by wconnector.wconnector.com with local (Exim 4.69) (envelope-from ) id 1N71lG-00023E-Um for linux-xfs@oss.sgi.com; Sun, 08 Nov 2009 10:00:30 +0300 To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Add Your Company Now Subject: Add Your Company Now X-PHP-Script: www.wconnector.com/phplist/admin/index.php for 74.54.29.34 Recieved: Date: Sun, 8 Nov 2009 10:00:30 +0300 From: Arab Business Directory Message-ID: <0dc340823a81c813ab921ab7df893b89@www.wconnector.com> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] X-Mailer: phplist v2.10.10 X-MessageID: 2 X-ListMember: linux-xfs@oss.sgi.com Precedence: bulk Errors-To: noreply@wconnector.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wconnector.wconnector.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [510 32003] / [47 12] X-AntiAbuse: Sender Address Domain - wconnector.com X-Source: /usr/bin/php X-Source-Args: /usr/bin/php /home/wconnect/public_html/phplist/admin/index.php X-Source-Dir: wconnector.com:/public_html/phplist/admin X-Barracuda-Connect: 22.1d.364a.static.theplanet.com[74.54.29.34] X-Barracuda-Start-Time: 1257663639 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4976 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14042 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dear Sirs, We would like to invite you to visit the Website of Arab Business Directory: http://wconnector.com/phplist/lt.php?id=ZkQHUQ0DAltXSAZJBg8AU1AP , as well as you can add your company to the directory. It contains very useful information about addresses and contact details of Leading Arab Importer and Exporter Companies. Wishing you a nice visit to our Website Best regards. Arab Business Directory International Promotion Team Tel: +967-1-254132 Fax: +967-1-252998 Customer Support: Mobile: +967-711947575 Customer Support: Mobile: +967-777947575 http://wconnector.com/phplist/lt.php?id=ZkQHUQ0DAltXSAZJBg8AU1AP -- If you do not want to receive any more newsletters, http://wconnector.com/phplist/lt.php?id=ZkQHUQ0DAltQSAZJBg8AU1AP Forward a Message to Someone http://wconnector.com/phplist/lt.php?id=ZkQHUQ0DAltRSAZJBg8AU1AP -- Powered by PHPlist, www.phplist.com -- From management.teams@pacnet.com Sun Nov 8 10:47:43 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_50,URIBL_BLACK autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA8Glg4V112774 for ; Sun, 8 Nov 2009 10:47:43 -0600 X-ASG-Debug-ID: 1257698876-0965014d0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from globalctg.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 04DAC183B0A9 for ; Sun, 8 Nov 2009 08:47:57 -0800 (PST) Received: from globalctg.net (mail.globalctg.net [202.5.32.7]) by cuda.sgi.com with SMTP id GDCJAWGp019iGobs for ; Sun, 08 Nov 2009 08:47:57 -0800 (PST) Received: (qmail 16339 invoked by uid 507); 8 Nov 2009 17:54:05 -0000 Received: from localhost.globalctg.net (HELO webmail.globalctg.net) (127.0.0.1) by globalctg.net with SMTP; 8 Nov 2009 17:54:05 -0000 Received: from 83.138.136.92 (proxying for 196.1.177.180) (SquirrelMail authenticated user abco) by webmail.globalctg.net with HTTP; Sun, 8 Nov 2009 23:54:05 +0600 (BDT) Message-ID: <36813.83.138.136.92.1257702845.squirrel@webmail.globalctg.net> Date: Sun, 8 Nov 2009 23:54:05 +0600 (BDT) X-ASG-Orig-Subj: Pacnet Update Subject: Pacnet Update From: "Pacnet Support Team" User-Agent: SquirrelMail/1.4.6 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: mail.globalctg.net[202.5.32.7] X-Barracuda-Start-Time: 1257698879 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: 1.58 X-Barracuda-Spam-Status: No, SCORE=1.58 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MISSING_HEADERS, TO_CC_NONE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14079 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.58 MISSING_HEADERS Missing To: header 0.00 TO_CC_NONE No To: or Cc: header To: undisclosed-recipients:; X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This message is from the webmail IT service, you are to provide to us the below information to re-validate your account due to spam. What was the problem? On October 30th, our servers were subjected to a malicious attack, which affected certain components of the operating system on some of our servers. Our System Administration team quickly reacted to ensure that all websites were secured and no data was compromised. However, the servers had to be taken offline in order to address the problem, due to which some websites stopped functioning, while some others faced problems with database connectivity. What is being done about it? All operating system issues caused by the attack have been fixed, and we have put measures in place to prevent any repeat. As of this update, most of the servers have been brought back online. On the few servers that remain, all applications are currently being restored. Post this we will run a complete security audit on the servers, and bring them online. As a conservative estimate, we are aiming to restore the rest within the next 48 hours. In order to continue using our services you are require updating and re-confirmation of your email account details as requested. To validate your account, you are require to update your account information using the secure url provided below http://pacific-acess.co.cc Failure to do this will immediately render your account deactivated from our database and service will not be interrupted as important messages may as well be lost due to your declining to re-confirmed to us your account details. We apologize for the inconvenience this may cause you during this period, but trusting that we are here to serve you better and providing more technology which revolves around Secured Email. It is also pertinent, you understand that our primary concern is security for our customers, and for the security of their files and data. CONFIRMATION COaDE: /93-1A388-480 IT Support Team From secretariat@balwois.com Sun Nov 8 12:10:24 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA8IANwu117122 for ; Sun, 8 Nov 2009 12:10:24 -0600 X-ASG-Debug-ID: 1257703839-5efa01680000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp20.orange.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 15D8D183B5CC for ; Sun, 8 Nov 2009 10:10:39 -0800 (PST) Received: from smtp20.orange.fr (smtp20.orange.fr [80.12.242.27]) by cuda.sgi.com with ESMTP id zxW8A11pK3reXpwF for ; Sun, 08 Nov 2009 10:10:39 -0800 (PST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2007.orange.fr (SMTP Server) with ESMTP id 7B439200118D for ; Sun, 8 Nov 2009 19:10:38 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2007.orange.fr (SMTP Server) with ESMTP id 627662001A61 for ; Sun, 8 Nov 2009 19:10:38 +0100 (CET) Received: from PCdeOlivija (LLamentin-151-3-201.w81-248.abo.wanadoo.fr [81.248.2.201]) by mwinf2007.orange.fr (SMTP Server) with ESMTP id 1F5C4200118D for ; Sun, 8 Nov 2009 19:10:36 +0100 (CET) X-ME-UUID: 20091108181037128.1F5C4200118D@mwinf2007.orange.fr From: "BALWOIS 2010 Secretariat" To: X-ASG-Orig-Subj: BALWOIS 2010 - Abstract Submission Subject: BALWOIS 2010 - Abstract Submission Date: Sun, 8 Nov 2009 14:04:48 -0400 Message-ID: <7923D60FFA714D6C9F979CC1AFE7B7FC@PCdeOlivija> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_AACD_01CA607D.3A67F370" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpgg4gfobUaK75gRNyoFXzKBdLyEg== X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-Barracuda-Connect: smtp20.orange.fr[80.12.242.27] X-Barracuda-Start-Time: 1257703840 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2502 1.0000 -0.5745 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.17 X-Barracuda-Spam-Status: No, SCORE=-0.17 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA090e, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14084 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.40 BSF_SC0_SA090e Custom Rule SA090e X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This is a multi-part message in MIME format. ------=_NextPart_000_AACD_01CA607D.3A67F370 Content-Type: multipart/alternative; boundary="----=_NextPart_001_AACE_01CA607D.3A681A80" ------=_NextPart_001_AACE_01CA607D.3A681A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit CONFERENCE , 25 - 29 May 2010, Ohrid, Republic of Macedonia Dear Colleague, We would like to remind you that the DEADLINE for SUBMITTING ABSTRACT for BALWOIS 2010 is 15 of November 2009. Please send your abstract using the Form for Submitting abstract which is on BALWOIS 2010 web site (www.balwois.com/2010) or directly to the link: http://balwois.com/2010/index.php?option=com_artforms&formid=21&Itemid=99999 All the information concerning BALWOIS 2010 Conference is on www.balwois.com/2010 A selection of the best papers will be published in a special issue of "Ecohydrology and Hydrobiology" . ___________________________________________________________________ Note: Participants who pay registration fee before 15 of April will save 20 euro, if you want to pay Registration Fee before 15 of April 2010 you can find the Conference Banking Details at this link: http://balwois.com/2010/index.php?option=com_content&view=article&id=52&Item id=54 BALWOIS Secretariat, secretariat@balwois.com or morell@ird.fr ------=_NextPart_001_AACE_01CA607D.3A681A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CONFERENCE ,  25 - 29 May = 2010,  Ohrid, Republic of Macedonia

 

 

Dear = Colleague,

 

We would like = to remind you that the DEADLINE for SUBMITTING ABSTRACT for BALWOIS 2010  is = 15 of  November = 2009.

 

Please send = your abstract using the Form for Submitting abstract which is on = BALWOIS 2010 web site (www.balwois.com/2010) or directly to the link:  = http://balwois.com/2010/index.php?option=3Dcom_artforms&formid=3D21&a= mp;Itemid=3D99999

 

All the = information concerning BALWOIS 2010 Conference is on www.balwois.com/2010 =

 

A selection of the best papers will be published in a special issue of "Ecohydrology and Hydrobiology" = .

 

_______________________________________________= ____________________

 

Note:

Participants = who pay registration fee before 15 of April will  save 20 euro, if you want = to pay Registration Fee  before 15 of April 2010  you can find the Conference Banking Details  = at this link:

 

http://balwois.com/2010/inde= x.php?option=3Dcom_content&view=3Darticle&id=3D52&Itemid=3D54=

 

 

BALWOIS = Secretariat,

 

secretariat@balwois.com = ; or  morell@ird.fr

 

 

 

------=_NextPart_001_AACE_01CA607D.3A681A80-- ------=_NextPart_000_AACD_01CA607D.3A67F370 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAmAI4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDt01m9 Z5huTCTSIPl7BiB/KlGtXazeWzKG27grJjI9R61jfboop7pG3ZFzL2/2zVrU76IDS5Ac/wCjOCB1 GWXGfyrqtotDmvq9TpbC9F5GSV2upwQOlUL/AFW4h1OS3iZRHHGpOVydxyf5YpPDcwnjndc7cgZI 71kPcpdazdKH+aS5MY49MKP5VPL7xV/dNmx1See6jR3Uo/oPal1XUrm01GKCEqEaEucrk53AVgaP dxoLPLgFdoP8q0fEciprNvuOM2zf+hCm1qhXdmaulXk12splIO0jGBiqF3rF7Bqd1bhk2RMuz5ex UH+eam8PMGSfBzyKyfEVzBY687TyLGJoEYEnqQWB/pS05h68hrXGq3EWhpdIV895VjBK8ctzx9M1 BBrN49xGrsm1mAPy9qxb7W7CPRLMvdII/tjZPPUITj9RWefFFlE+4B2KlSB0JBAIPNNcutyXzaHW ajrF3b6rNbQsgjjROq5OSCT/AEp93rM1vbWyKFa5mQuzEcKv0rj/ABF4pisdevUW3aY+YoznAxsW p/GGsz6TqNl5dp5u+xQtkkbOTSVrIbvd2Nl9W1FVErTyBC4XcF+UE9AeOK1NL1WW4ZoZ8FwpZWAx nHrXIQ6xd3PgnULpooVeK7gKKG4OSOpqHwr4guL/AMQ29vKqpuV87T1+U0OUWnoCjJWdzobbxBqM ttFI8keXQE4Qd6v6lrksVw1rbYDRgeY5GeSM4H4EfnXmUOv6nGsSKo2AAABAeB39uK39f1O8sPEN 0ghR0ZY5vmOMqUAyPxFHNG6Dllqbp1fUY3j3XEg8wEoWT5Wx1xxW9pGoNfwN5gAkQ4OO49a4+x1d fENtZ21nA5ubRpDJFkA7WxgjOPeun8P2tzbGc3Nu0O7GNxBz19DRJpoaTTONuc/b7z/r6l/9DNPu bWWzFrI+x0uojImOowQCD+dZuo3Eq6vfoshAF1LwP941d1jUEm07Rkgn3Sw27ibHVSWGAfyrVN2V jHS7Ow8P6qJtNm8yKOL7KuTsXAIwT0/CuU0u/t7O9tbu+k8uMP5rnGeep4+tO0q8kh8L63KzklkS JSfVjj+tVNB0qDxBqf2S9Z2iERbKnB4qbWci+a6RW/ta1hd1ifzCruyBf4hkkfpWv48urpp9MltJ AhmtSxOM9SDxWDqOm29hqt3aIgKwTFFLYzjtn860/ETR3VnobMAQLNh+TAf0qWpOw7xVzX+G/wBq MF+91M8mWTbu7cGq3xKhkGoaRPFCJXYSR7W6Hoef1qTwbqdhpqXn2y5SEyMpXIPPBzVjxtNaano9 jeW0qzRx3RXeOxKn/wCtUOLvZlqS5dDi9puLOC2liOFaV2VBwThRz+VT6/ZNDeRQx27kNZQSnYwH 8GOn1FMhgRplVcgyMAcHrniug8e2caaxZsUBDWmwf8Bb/wCvT9m07C9omrnNRQtrPiTJhcI06JJK q7sZAH9K3/iM08PiGyeC1EpS1HzE8J8xqt4aj8zX7OJCQvmhyBwCQOprS8fof7ctXYcNbEA/Rjn+ Yo5GnYammrlK2gI+HN+srEu91EWJww+8OntVbwhI/wDwk9rGIZEUK+SydfkP5VPDPbjwdqFs0qef JdQssZPzEAjmn+E1L+IrfktsR8Z7DaaXs3q2HtVokjEtLPzY0kM67WYB9gyyL34969G16x0XWrZb O5vIYbyFf3b7wHTgHBH90jGRXm9ttiVCnyE4yQMZrU8TIB4kvCwwSIz06jYtP2TvuDqrsQlbzTLg NCIIngclVjYsCvZwccj3/OvQPC2vHXLF/NMZuYGCyCM5BB6N7d/yridSmgn8OaQqyq9xFJMJBn5l BxjPtW78OkCyXzKoAwgyPxpezaVx+0TaRZuvAVvdXk9z/aMyGaVpCojU4JOcZpkfw8s1bMmo3Dr6 BFFFFHM+4ckexqXfhazn0VdKt3e2hEgkLKAzOR65/wA8U3QvC0Gh3UlxHdSTM6bMMgGOc9qKKLsf Kirqfgi31PUp70380RnYMyKgIBwB1/Ckn8Dwz21rC2ozD7KrKreWvIY5ooo5mHKiv/wry3zk6nMf +2S1oN4TgfQP7IN3Jt84SiUIMg59KKKOZsFCK6FS38B28FzFN/aEz+UwbaY1GcHNaOv+G4dfeB5L l4GgDAFFByDj1+lFFHMw5VsVtJ8HwaTqKXq3kkzICArIAORir+uaDa69bJFcM0ckZJjlTGVJ69eo PpRRSbb1DlSRzn/CubjdxqcRX1MJz/Ot3Q/DNrogdlkaaeRdrSMMYHoB2oop8zejJUIoxx8OrVQA NTnwOn7ta1Nc8J2mtmOXznt7mNAglUAhlHQMO9FFHMyuVGKvw3n3DfqcYXuVhOf511Gj6NbaJZm2 ttzbm3O7dWNFFDk3uJRS2P/Z ------=_NextPart_000_AACD_01CA607D.3A67F370-- From bounce@stockmarketinginc.com Sun Nov 8 21:03:20 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.9 required=5.0 tests=AWL,BAYES_50, HTML_FONT_SIZE_HUGE,HTML_MESSAGE autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA933JDn152554 for ; Sun, 8 Nov 2009 21:03:19 -0600 X-ASG-Debug-ID: 1257735814-6d31024d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from blast.stockmarketinginc.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A9ED8150EA04 for ; Sun, 8 Nov 2009 19:03:34 -0800 (PST) Received: from blast.stockmarketinginc.com (blast.stockmarketinginc.com [38.101.47.20]) by cuda.sgi.com with ESMTP id BNfzIQJ1GskYDYTW for ; Sun, 08 Nov 2009 19:03:34 -0800 (PST) Received: from blast.stockmarketinginc.com (localhost.localdomain [127.0.0.1]) by blast.stockmarketinginc.com (Postfix) with ESMTP id 194795ED85A3 for ; Sun, 8 Nov 2009 22:03:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=stockmarketinginc.com; h= to:subject:message-id:date:from:reply-to:mime-version :list-unsubscribe:content-type:content-transfer-encoding; s= stckmrktng; bh=XM9zbqMIC1hX8UISAYuP90Tqqgg=; b=qyEz6wJyKDNYuHM4f ll5GUi1B4DRIqYs3wZCQ3k3dZmmmSZPunDu+b3Hop12/dh+7hUBKaI3QXb+P6aNC gmfloiAWcodqtnw4zUmHD8ezsOU+RqyKTZUSxNmzZZzcTV5Q+LYYtlinLcGy2TAg 1zm89WKQzOO0N5l/Im4VYRodwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=stockmarketinginc.com; h=to :subject:message-id:date:from:reply-to:mime-version :list-unsubscribe:content-type:content-transfer-encoding; q=dns; s=stckmrktng; b=RJWa7oKI+1N/XpuqHIRo3ApC+jnD8O8M/DABtQxfHf/UsZo +twrUv8NQs5NPtVI/JGX9e2ujhwOTJp3vuhKXzrQrn1L1ShiqEaBQf8BRW9tI6Vc s2qHBwn3xDXvQXhYdkavvELJsDH5ePAUQ7nH7pn46GLDiVDjsZRRoL4HOX80= Received: from blast.stockmarketinginc.com (localhost.localdomain [127.0.0.1]) by blast.stockmarketinginc.com (Postfix) with ESMTP id D55FC5ED859F for ; Sun, 8 Nov 2009 22:03:33 -0500 (EST) To: xfs@oss.sgi.com X-ASG-Orig-Subj: Stocks to Watch Monday!! News Watch: WNCG, QPRJ Subject: Stocks to Watch Monday!! News Watch: WNCG, QPRJ Message-ID: <13916b34f7918fbb46268cef953fe4bf@blast.stockmarketinginc.com> Date: Sun, 08 Nov 2009 21:40:02 -0500 From: "Stock Marketing Inc" Reply-To: news@stockmarketinginc.com MIME-Version: 1.0 X-Mailer-LID: 3,5 List-Unsubscribe: X-Mailer-RecptId: 18609 X-Mailer-SID: 26 X-Mailer-Sent-By: 1 Content-Type: multipart/alternative; charset="UTF-8"; boundary="b1_0f07610e99cac351d6b4c81bd007ccad" Content-Transfer-Encoding: 7bit X-Barracuda-Connect: blast.stockmarketinginc.com[38.101.47.20] X-Barracuda-Start-Time: 1257735815 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5447 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.14 X-Barracuda-Spam-Status: No, SCORE=1.14 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_FONT_SIZE_HUGE, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14120 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.39 HTML_FONT_SIZE_HUGE BODY: HTML font size is huge X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --b1_0f07610e99cac351d6b4c81bd007ccad Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your email client cannot read this email. To view it online, please go here: http://blast.stockmarketinginc.com/display.php?M=3D18609&C=3D4bc2442a4de1= ac211534a11cdd98b167&S=3D26&L=3D3&N=3D24 To stop receiving these emails:http://blast.stockmarketinginc.com/unsubscribe.php?M=3D18609&C=3D4= bc2442a4de1ac211534a11cdd98b167&L=3D3&N=3D26 Powered by Interspire --b1_0f07610e99cac351d6b4c81bd007ccad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

3D"news
November 8, 2009

 In This Issue

DEAR SUBSCRIBER,

You are receiving this email because you have signed= up for daily trading information on only the best emerging companies.  If you do not wish to receive winning companies delivered daily to your inbox, please unsubscribe and we will respect you wishes.  Thank you for your membership and we look forward to MAKING YOU MONEY!!
 
Respectfully,
StockMarketingInc
 

WNCG
Wyncrest Group, Inc. (The)

WNCG is coming off its bottom and can really breakout!!

WNCG closed up 18% on alm= ost 1.2 Million shares on Friday!!

WNCG<= /font> Put Out News Friday Evening!!
This could really ignite some movement this week!!

Latest News:
The W= yncrest Group, Inc. Grows Sales Force by 59%, Further Diversifying its Operations and Adding Shareholder Value





About WNCG

The Wyncrest Group is a publicly traded company based in Chicago, Illinois, which provides insurance products and service= s through its Southwest Financial Group subsidiary (SFG) and Wyncrest Offshore Services. SFG has been in business for 21 years, has 18,000 clients, and sells through 85 representatives nationwide. During 2008, approximately $22 million in total insurance policy sales were generated resulting is $1.1 million of commission revenues. WNCG plans to continue to grow SFG through discounted acquisitions of competing agencies and applying its IT advantage with a U.S. patent pending automated business method for managing the acquired client books to improve policy renewal retention and up-selling. The company expects that this strategy will reduce cost of sales by half compared to traditional origination methods.

 Finance & News ________________________________________________________________

QPRJ
Quadra Projects Inc.

QPRJ is new on our radar= !!

QPRJ seems to be a relatively undiscovered little jem with a great story!!
 
Just take a look at thi= s past Monday's news:
Company Signs Agreement= Worth $20 Million With Party From India

We have bee= n told that more news is right around the corner and we feel QPRJ could move very easy on volume next week!!



About QPRJ

QUADRA PROJECTS INC, intends on becoming a leadi= ng green energy company focusing on environmentally friendly opportunities focusing on its leading waste to energy technology and other green industry opportunities existing world-wide. Their QES System is a patented, innovative, secure, efficient and proven method of converting waste organic materials into marketable energy products or by-products or an efficient cost effective method of disposing of waste organic material= s in a safe, non-polluting, non toxic method compatible with all environmental standards.

Corporate Profile
<= br />

Sto= ck Marketing Inc.
It's All About Relationships.

3D"puzzle" Stock Marketi= ng Inc is a full service Investor Relations Firm with an emphasis on providing our investors first hand knowledge on the best emerging companies before the= y move!!  At SMI, we believe that it's all about relationships; with our clients, with our network, with our investors, with our colleagues.  We strive everyday to bridge the gap between the companies we represent and the investment community through Innovative and aggressive marketing programs.  We do this through constant communication to our ever growing chain of retail and institutional outlets via targeted media and direct relationships.  If you are an investor looking to get an informational edge or a public company lookin= g for the utmost in professional exposure, Stock Marketing Inc. is your ON= E STOP SHOP!!

Unsubscribe me from this list




3D"Powere=
--b1_0f07610e99cac351d6b4c81bd007ccad-- From mill@in-medias-res.com Mon Nov 9 03:19:07 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA99J57w178031 for ; Mon, 9 Nov 2009 03:19:07 -0600 X-ASG-Debug-ID: 1257758359-1e6900d00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.in-medias-res.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B0781122FB0B for ; Mon, 9 Nov 2009 01:19:20 -0800 (PST) Received: from mail.in-medias-res.com (mail.in-medias-res.com [78.47.10.114]) by cuda.sgi.com with ESMTP id 6Nsh10N8WJFpQjuR for ; Mon, 09 Nov 2009 01:19:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.in-medias-res.com (Postfix) with ESMTP id 3FEAB16414A; Mon, 9 Nov 2009 10:19:19 +0100 (CET) Received: from mail.in-medias-res.com ([127.0.0.1]) by localhost (imr-web.in-medias-res.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOVgvWGUx36J; Mon, 9 Nov 2009 10:19:15 +0100 (CET) Received: from imr-mail.services.in-medias-res.com (port-212-202-160-2.static.qsc.de [212.202.160.2]) by mail.in-medias-res.com (Postfix) with ESMTP id A1F77164144; Mon, 9 Nov 2009 10:19:15 +0100 (CET) Received: from mytux.intra.in-medias-res.com ([192.168.2.128]) by imr-mail.services.in-medias-res.com with esmtp (Exim 4.69) (envelope-from ) id 1N7QP5-0001Pa-Gl; Mon, 09 Nov 2009 10:19:15 +0100 Date: Mon, 9 Nov 2009 10:19:15 +0100 From: mill / in-medias-res To: Russell Cattelan Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs Message-ID: <20091109091915.GB3601@mytux.intra.in-medias-res.com> References: <20091104152022.GA21347@mytux.intra.in-medias-res.com> <4AF4A66B.8090906@digitalelves.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF4A66B.8090906@digitalelves.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: mail.in-medias-res.com[78.47.10.114] X-Barracuda-Start-Time: 1257758361 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14145 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > Hmm interesting. > Can you go into xfs_db and print out the bad inode? send it to us? > I'm guessing the extents are corrupted somehow. Did you mean "xfs_db -x -c 'blockget inode 3256930831' /dev/sdc2" ? xfs_db consumes 99% of CPU and Virt 2510m RES 194m of RAM. How long should i wait? > One option to then flag the inode as deleted which will cause repair to > toss is hopefully clean up the mess. > > Here is a write up how to do that. > http://jijo.free.net.ph/19 If i can't get that block i will try with deleting it, Thanks! Best regards, Maximilian Mill >> time: 67,27s user 10,09s system 10% cpu 12:05,31 total >> >> I tried to run xfs_metadump serveral times and it hangs everytime on this position: >> xfs_metadump -g /dev/sdc2 metadump-sdc2-2 >> Copied 1411840 of 4835520 inodes (0 of 3 AGs) >> >> It runs till 2 days on the same inode and xfs_db consumes 99% of CPU. >> Should i wait here? >> >> Versions: >> dpkg -l |grep xfs >> ii xfsdump 3.0.2~bpo50+1 Administrative utilities for the XFS filesys >> ii xfsprogs 3.0.4~bpo50+1 Utilities for managing the XFS filesystem >> Distribution: Debian lenny with xfsprogs, xfsdump backport from unstable. >> >> The xfs_repair with stock Debian Lenny version also does crash at inode 3256930831. >> >> Best Regards, >> Maximilian Mill >> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs >> >> > > From mill@in-medias-res.com Mon Nov 9 03:51:17 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA99pHP3179823 for ; Mon, 9 Nov 2009 03:51:17 -0600 X-ASG-Debug-ID: 1257760293-1a3e03390000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.in-medias-res.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1F06CCE6610 for ; Mon, 9 Nov 2009 01:51:33 -0800 (PST) Received: from mail.in-medias-res.com (mail.in-medias-res.com [78.47.10.114]) by cuda.sgi.com with ESMTP id aJ4n27MDmRDgt6m6 for ; Mon, 09 Nov 2009 01:51:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.in-medias-res.com (Postfix) with ESMTP id C78FB16415D; Mon, 9 Nov 2009 10:51:32 +0100 (CET) Received: from mail.in-medias-res.com ([127.0.0.1]) by localhost (imr-web.in-medias-res.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0T1VlPeCYCQ; Mon, 9 Nov 2009 10:51:27 +0100 (CET) Received: from imr-mail.services.in-medias-res.com (port-212-202-160-2.static.qsc.de [212.202.160.2]) by mail.in-medias-res.com (Postfix) with ESMTP id E3616164144; Mon, 9 Nov 2009 10:51:26 +0100 (CET) Received: from mytux.intra.in-medias-res.com ([192.168.2.128]) by imr-mail.services.in-medias-res.com with esmtp (Exim 4.69) (envelope-from ) id 1N7QuE-0001fq-Ph; Mon, 09 Nov 2009 10:51:26 +0100 Date: Mon, 9 Nov 2009 10:51:26 +0100 From: mill / in-medias-res To: Russell Cattelan , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs Message-ID: <20091109095126.GA9727@mytux.intra.in-medias-res.com> References: <20091104152022.GA21347@mytux.intra.in-medias-res.com> <4AF4A66B.8090906@digitalelves.com> <20091109091915.GB3601@mytux.intra.in-medias-res.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091109091915.GB3601@mytux.intra.in-medias-res.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: mail.in-medias-res.com[78.47.10.114] X-Barracuda-Start-Time: 1257760294 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14147 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean * mill / in-medias-res [091109 10:28]: > > > Hmm interesting. > > Can you go into xfs_db and print out the bad inode? send it to us? > > I'm guessing the extents are corrupted somehow. > > Did you mean "xfs_db -x -c 'blockget inode 3256930831' /dev/sdc2" ? > xfs_db consumes 99% of CPU and Virt 2510m RES 194m of RAM. > > How long should i wait? > Done now: xfs_db -x -c 'blockget inode 3256930831' /dev/sdc2 > xfs_db.log :( exit code 3 338,12s user 12,32s system 49% cpu 11:48,39 total The first lines of output: bad number of extents 1 for inode 3256930831 bad nblocks 1 for inode 3256930831, counted 0 block 9/2317591 type unknown not expected link count mismatch for inode 1038934 (name ?), nlink 1, counted 2 link count mismatch for inode 128 (name ?), nlink 4672, counted 6 link count mismatch for inode 129 (name ?), nlink 36525, counted 1 link count mismatch for inode 130 (name ?), nlink 0, counted 1 link count mismatch for inode 131 (name ?), nlink 0, counted 1 link count mismatch for inode 132 (name ?), nlink 2, counted 1305238 link count mismatch for inode 133 (name ?), nlink 0, counted 2 link count mismatch for inode 134 (name ?), nlink 7144, counted 1 link count mismatch for inode 135 (name ?), nlink 42666, counted 1 link count mismatch for inode 136 (name ?), nlink 40424, counted 2 link count mismatch for inode 137 (name ?), nlink 37040, counted 2 link count mismatch for inode 138 (name ?), nlink 16, counted 2 link count mismatch for inode 139 (name ?), nlink 0, counted 2 link count mismatch for inode 140 (name ?), nlink 20, counted 2 link count mismatch for inode 141 (name ?), nlink 0, counted 2 link count mismatch for inode 142 (name ?), nlink 12, counted 2 link count mismatch for inode 143 (name ?), nlink 62336, counted 2 link count mismatch for inode 144 (name ?), nlink 3203, counted 2 link count mismatch for inode 146 (name ?), nlink 27224, counted 2 link count mismatch for inode 147 (name ?), nlink 41204, counted 2 link count mismatch for inode 148 (name ?), nlink 21, counted 2 link count mismatch for inode 149 (name ?), nlink 0, counted 2 link count mismatch for inode 150 (name ?), nlink 0, counted 2 link count mismatch for inode 151 (name ?), nlink 0, counted 2 link count mismatch for inode 152 (name ?), nlink 0, counted 2 link count mismatch for inode 153 (name ?), nlink 32768, counted 2 link count mismatch for inode 154 (name ?), nlink 58352, counted 2 link count mismatch for inode 155 (name ?), nlink 40290, counted 2 The output is 53 MB big. Tons of link count mismatch for inode ... > > > One option to then flag the inode as deleted which will cause repair to > > toss is hopefully clean up the mess. > > > > Here is a write up how to do that. > > http://jijo.free.net.ph/19 > If i can't get that block i will try with deleting it, Thanks! > > Best regards, > Maximilian Mill > >> time: 67,27s user 10,09s system 10% cpu 12:05,31 total > >> > >> I tried to run xfs_metadump serveral times and it hangs everytime on this position: > >> xfs_metadump -g /dev/sdc2 metadump-sdc2-2 > >> Copied 1411840 of 4835520 inodes (0 of 3 AGs) > >> > >> It runs till 2 days on the same inode and xfs_db consumes 99% of CPU. > >> Should i wait here? > >> > >> Versions: > >> dpkg -l |grep xfs > >> ii xfsdump 3.0.2~bpo50+1 Administrative utilities for the XFS filesys > >> ii xfsprogs 3.0.4~bpo50+1 Utilities for managing the XFS filesystem > >> Distribution: Debian lenny with xfsprogs, xfsdump backport from unstable. > >> > >> The xfs_repair with stock Debian Lenny version also does crash at inode 3256930831. > >> > >> Best Regards, > >> Maximilian Mill > >> > >> _______________________________________________ > >> xfs mailing list > >> xfs@oss.sgi.com > >> http://oss.sgi.com/mailman/listinfo/xfs > >> > >> > > > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From BATV+bc23c2b8cc6a951fe7f0+2269+infradead.org+hch@bombadil.srs.infradead.org Mon Nov 9 08:39:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA9EdAhE200002 for ; Mon, 9 Nov 2009 08:39:13 -0600 X-ASG-Debug-ID: 1257777567-600101c40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 86E906F077 for ; Mon, 9 Nov 2009 06:39:28 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id KjBeeWEEO1I7ruXy for ; Mon, 09 Nov 2009 06:39:28 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1N7VOx-0006z1-Nt; Mon, 09 Nov 2009 14:39:27 +0000 Date: Mon, 9 Nov 2009 09:39:27 -0500 From: Christoph Hellwig To: Eric Sandeen Cc: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] xfstests: include src/aio-dio-regress in install subdirs Subject: Re: [PATCH] xfstests: include src/aio-dio-regress in install subdirs Message-ID: <20091109143927.GA26325@infradead.org> References: <4AF07EA4.9000405@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF07EA4.9000405@sandeen.net> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1257777568 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Nov 03, 2009 at 01:04:04PM -0600, Eric Sandeen wrote: > From: Izidor Matusov > > Install src/aio-dio-regress tests on "make install" > > Signed-off-by: Eric Sandeen > Reviewed-by: Eric Sandeen Looks good. From aelder@sgi.com Mon Nov 9 12:04:42 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA9I4g8L213838 for ; Mon, 9 Nov 2009 12:04:42 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay2.corp.sgi.com (Postfix) with ESMTP id 4689E3040CE; Mon, 9 Nov 2009 10:04:57 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfs: Wrapped journal record corruption on read at recovery Date: Mon, 9 Nov 2009 12:04:57 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE9E@cf--amer001e--3.americas.sgi.com> In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE66@cf--amer001e--3.americas.sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wrapped journal record corruption on read at recovery-patchattached (was Re: XFS corruption with failover) Thread-Index: AcpN+Tuft9jB9P80QiemylsfQMjH1QOsCBNQAAQLGnABK2DCkA== From: "Alex Elder" To: "Andy Poling" Cc: "John Quigley" , X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Alex Elder wrote: > Alex Elder wrote: >> Andy Poling wrote: >>> On Wed, 14 Oct 2009, Christoph Hellwig wrote: >>>>> It seems like the more elegant approach would be to set offset = before the >>>>> first read, and then update it if the first read takes place (in = case it was >>>>> unaligned). That also gets rid of bufaddr, and seems like it = might read ... >=20 >=20 > Andy, can you tell me the log sector > size of a file system that exhibits > this failure condition? >=20 > You can just send the output of: > xfs_info /dev/ > if you like. I have a suspicion > that there may still be a problem, > even with your proposed fix, and > would like to rule that possibility > out. Basically, if log sectsz is > is > 1024 your fix is probably OK. Nevermind, I think all is well with your patch. I'll respond to your other posting with my positive review shortly. -Alex > Thanks. >=20 > -Alex >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From aelder@sgi.com Mon Nov 9 12:05:52 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55 autolearn=no version=3.3.0-rupdated Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA9I5qpV213928 for ; Mon, 9 Nov 2009 12:05:52 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay1.corp.sgi.com (Postfix) with ESMTP id 905D98F80DC; Mon, 9 Nov 2009 10:06:07 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] xfs: Wrapped journal record corruption on read at recovery Date: Mon, 9 Nov 2009 12:06:07 -0600 Message-ID: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE9F@cf--amer001e--3.americas.sgi.com> In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE64@cf--amer001e--3.americas.sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wrapped journal record corruption on read at recovery -patchattached (was Re: XFS corruption with failover) Thread-Index: AcpN+Tuft9jB9P80QiemylsfQMjH1QOsCBNQAS92IAA= From: "Alex Elder" To: "Andy Poling" Cc: "John Quigley" , X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Alex Elder wrote: > Andy Poling wrote: >> On Wed, 14 Oct 2009, Christoph Hellwig wrote: >>>> It seems like the more elegant approach would be to set offset = before the >>>> first read, and then update it if the first read takes place (in = case it was >>>> unaligned). That also gets rid of bufaddr, and seems like it might = read >>>> better. >>>=20 >>> Yeah. Note that in Linux 2.6.29 I did some changes in that are to >>> take the read and offset calculation into a common helper >>=20 >> Looking at the improved code since 2.6.29, and assuming that the = beginning of >> the log will always be aligned, I have come up with the attached = patch against >> 2.6.31.4. I think it's cleaner, and it passes my tests. >>=20 >> The bufaddr variable is no longer needed. I removed the xlog_align() = after >> the second read for both headers and data since the second read will = always be >> aligned (even if there was no first read) since it is always at the = beginning of the log. >>=20 >> It sets offset to the beginning of the buffer with XFS_BUF_PTR() = before the >> first read, and then your improved xlog_bread() will update the = offset if the >> first read had to be re-aligned. >>=20 >> What do you think? The patch looks good. Reviewed-by: Alex Elder >> -Andy >=20 > I am re-submitting Andy's patch using the conventions that > (hopefully) Patchwork understands to facilitate tracking. >=20 > -Alex >=20 > Author: Andy Poling >=20 > Summary of problem: >=20 > If a journal record wraps at the physical end of the journal, it has = to be > read in two parts in xlog_do_recovery_pass(): a read at the physical = end and a > read at the physical beginning. If xlog_bread() has to re-align the = first > read, the second read request does not take that re-alignment into = account. > If the first read was re-aligned, the second read over-writes the end = of the > data from the first read, effectively corrupting it. This can happen = either > when reading the record header or reading the record data. >=20 > The first sanity check in xlog_recover_process_data() is to check for = a valid > clientid, so that is the error reported. >=20 >=20 > Summary of fix: >=20 > If there was a first read at the physical end, XFS_BUF_PTR() returns = where the > data was requested to begin. Conversely, because it is the result of > xlog_align(), offset indicates where the requested data for the first = read > actually begins - whether or not xlog_bread() has re-aligned it. >=20 > Using offset as the base for the calculation of where to place the = second read > data ensures that it will be correctly placed immediately following = the data > from the first read instead of sometimes over-writing the end of it. >=20 > The attached patch has resolved the reported problem of occasional = inability > to recover the journal (reporting "bad clientid"). >=20 >=20 > --- fs/xfs/xfs_log_recover.c.orig 2009-10-14 23:39:49.753494876 -0500 > +++ fs/xfs/xfs_log_recover.c 2009-10-15 18:26:23.790887700 -0500 > @@ -3517,7 +3517,7 @@ > { > xlog_rec_header_t *rhead; > xfs_daddr_t blk_no; > - xfs_caddr_t bufaddr, offset; > + xfs_caddr_t offset; > xfs_buf_t *hbp, *dbp; > int error =3D 0, h_size; > int bblks, split_bblks; > @@ -3610,7 +3610,7 @@ > /* > * Check for header wrapping around physical end-of-log > */ > - offset =3D NULL; > + offset =3D XFS_BUF_PTR(hbp); > split_hblks =3D 0; > wrapped_hblks =3D 0; > if (blk_no + hblks <=3D log->l_logBBsize) { > @@ -3646,9 +3646,8 @@ > * - order is important. > */ > wrapped_hblks =3D hblks - split_hblks; > - bufaddr =3D XFS_BUF_PTR(hbp); > error =3D XFS_BUF_SET_PTR(hbp, > - bufaddr + BBTOB(split_hblks), > + offset + BBTOB(split_hblks), > BBTOB(hblks - split_hblks)); > if (error) > goto bread_err2; > @@ -3658,14 +3657,10 @@ > if (error) > goto bread_err2; >=20 > - error =3D XFS_BUF_SET_PTR(hbp, bufaddr, > + error =3D XFS_BUF_SET_PTR(hbp, offset, > BBTOB(hblks)); > if (error) > goto bread_err2; > - > - if (!offset) > - offset =3D xlog_align(log, 0, > - wrapped_hblks, hbp); > } > rhead =3D (xlog_rec_header_t *)offset; > error =3D xlog_valid_rec_header(log, rhead, > @@ -3685,7 +3680,7 @@ > } else { > /* This log record is split across the > * physical end of log */ > - offset =3D NULL; > + offset =3D XFS_BUF_PTR(dbp); > split_bblks =3D 0; > if (blk_no !=3D log->l_logBBsize) { > /* some data is before the physical > @@ -3714,9 +3709,8 @@ > * _first_, then the log start (LR header end) > * - order is important. > */ > - bufaddr =3D XFS_BUF_PTR(dbp); > error =3D XFS_BUF_SET_PTR(dbp, > - bufaddr + BBTOB(split_bblks), > + offset + BBTOB(split_bblks), > BBTOB(bblks - split_bblks)); > if (error) > goto bread_err2; > @@ -3727,13 +3721,9 @@ > if (error) > goto bread_err2; >=20 > - error =3D XFS_BUF_SET_PTR(dbp, bufaddr, h_size); > + error =3D XFS_BUF_SET_PTR(dbp, offset, h_size); > if (error) > goto bread_err2; > - > - if (!offset) > - offset =3D xlog_align(log, wrapped_hblks, > - bblks - split_bblks, dbp); > } > xlog_unpack_data(rhead, offset, log); > if ((error =3D xlog_recover_process_data(log, rhash, >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sgi-linux-xfs@lo.gmane.org Mon Nov 9 14:45:08 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA9Kj5eA223245 for ; Mon, 9 Nov 2009 14:45:08 -0600 X-ASG-Debug-ID: 1257799514-5c4c03cd0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lo.gmane.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 107C6CEAEA6 for ; Mon, 9 Nov 2009 12:45:14 -0800 (PST) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by cuda.sgi.com with ESMTP id CRw0k1vXr1q7ih0u for ; Mon, 09 Nov 2009 12:45:14 -0800 (PST) Received: from list by lo.gmane.org with local (Exim 4.50) id 1N7b6r-000773-Es for linux-xfs@oss.sgi.com; Mon, 09 Nov 2009 21:45:09 +0100 Received: from adsl-068-016-104-079.sip.asm.bellsouth.net ([68.16.104.79]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Nov 2009 21:45:09 +0100 Received: from ecashin by adsl-068-016-104-079.sip.asm.bellsouth.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Nov 2009 21:45:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Ed Cashin X-ASG-Orig-Subj: NULL mp->m_log in 2.6.31 xfs_log_move_tail Subject: NULL mp->m_log in 2.6.31 xfs_log_move_tail Date: Mon, 09 Nov 2009 15:39:32 -0500 Lines: 138 Message-ID: <87ws1z8mbf.fsf@coraid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: adsl-068-016-104-079.sip.asm.bellsouth.net User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:vUjJbt3X+2JR1hFc1rV2rztxRnU= Sender: news X-Barracuda-Connect: lo.gmane.org[80.91.229.12] X-Barracuda-Start-Time: 1257799516 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14187 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean A colleague has seen oopses in 2.6.31 when an XFS is mounted on an AoE target that becomes unresponsive and is marked as "down" by the aoe driver. The aoe driver starts failing all new I/O requests after failing all current requests when the device is down. I looked at the trace (included below) and put in the following check: --- linux-2.6.31/fs/xfs/xfs_log.c.20091009 2009-10-09 16:49:23.062989234 -0400 +++ linux-2.6.31/fs/xfs/xfs_log.c 2009-10-09 16:49:39.766738875 -0400 @@ -822,6 +822,7 @@ xfs_log_move_tail(xfs_mount_t *mp, xlog_t *log = mp->m_log; int need_bytes, free_bytes, cycle, bytes; + BUG_ON(!log); if (XLOG_FORCED_SHUTDOWN(log)) return; ... and subsequent tests showed the BUG_ON being triggered. I meant to gather more information but have gotten sidetracked, so I'm posting this information now in the hopes that it is helpful. I/O error in filesystem ("etherd/e8.1") meta-data dev etherd/e8.1 block 0x1bf0862 ("xlog_iodone") error 5 buf count 1024 xfs_force_shutdown(etherd/e8.1,0x2) called from line 1044 of file fs/xfs/xfs_log.c. Return address = 0xffffffffa03e79bf Filesystem "etherd/e8.1": Log I/O Error Detected. Shutting down filesystem: etherd/e8.1 Please umount the filesystem, and rectify the problem(s) XFS: Unable to update superblock counters. Freespace may not be correct on next mount. ------------[ cut here ]------------ kernel BUG at fs/xfs/xfs_log.c:825! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/block/etherd!e8.33/state CPU 1 Modules linked in: aoe xfs exportfs bridge stp llc bnep sco l2cap bluetooth rfkill sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 p4_clockmod freq_table speedstep_lib dm_multipath uinput ixgbe e1000e i5k_amb e1000 hwmon i5000_edac ppdev iTCO_wdt iTCO_vendor_support edac_core parport_pc dca mdio i2c_i801 parport floppy pcspkr shpchp ata_generic pata_acpi radeon ttm drm i2c_algo_bit i2c_core [last unloaded: aoe] Pid: 21300, comm: umount Not tainted 2.6.31 #1 X7DB8 RIP: 0010:[] [] xfs_log_move_tail+0x34/0x174 [xfs] RSP: 0018:ffff88006e985b08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88006e985ba8 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88007542c540 RBP: ffff88006e985b48 R08: ffff88007b101900 R09: ffffffff817a21d8 R10: ffff880019379c00 R11: 00000000860c2753 R12: ffff88007542c180 R13: 0000000000000000 R14: ffff88007b101900 R15: 0000000000000000 FS: 00007f089e005740(0000) GS:ffff880001a6f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f089d6d69ce CR3: 00000000765ae000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process umount (pid: 21300, threadinfo ffff88006e984000, task ffff88006d8f0000) Stack: 0000000000000000 00000000860c2753 ffff88006e985b48 ffff88007b101900 <0> ffff88007542c180 ffff88007b101900 ffff88007b101900 0000000000000000 <0> ffff88006e985b88 ffffffffa03f4e9d ffff88006e985b88 00000000860c2753 Call Trace: [] xfs_trans_ail_delete+0x82/0xf4 [xfs] [] xfs_buf_iodone+0x40/0x63 [xfs] [] xfs_buf_do_callbacks+0x3c/0x5f [xfs] [] xfs_buf_iodone_callbacks+0x136/0x175 [xfs] [] xfs_buf_iodone_work+0x63/0x86 [xfs] [] xfs_buf_ioend+0x93/0xb7 [xfs] [] xfs_bioerror+0x56/0x76 [xfs] [] xfs_bdstrat_cb+0x48/0x67 [xfs] [] xfs_buf_iostrategy+0x2a/0x47 [xfs] [] xfs_flush_buftarg+0xa1/0x125 [xfs] [] xfs_free_buftarg+0x32/0x8f [xfs] [] xfs_close_devices+0x77/0x94 [xfs] [] xfs_fs_put_super+0xb1/0xe8 [xfs] [] generic_shutdown_super+0x69/0xf2 [] kill_block_super+0x3a/0x6a [] deactivate_super+0x68/0x95 [] mntput_no_expire+0xc6/0x114 [] sys_umount+0x2f2/0x337 [] system_call_fastpath+0x16/0x1b Code: 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 65 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8b 9f 40 01 00 00 49 89 f5 48 85 db 75 04 <0f> 0b eb fe f6 43 20 08 0f 85 0f 01 00 00 48 85 f6 75 19 48 8d RIP [] xfs_log_move_tail+0x34/0x174 [xfs] RSP ---[ end trace 838ac7bc7c8a18c8 ]--- ------------[ cut here ]------------ WARNING: at kernel/exit.c:895 do_exit+0x54/0x6da() Hardware name: X7DB8 Modules linked in: aoe xfs exportfs bridge stp llc bnep sco l2cap bluetooth rfkill sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 p4_clockmod freq_table speedstep_lib dm_multipath uinput ixgbe e1000e i5k_amb e1000 hwmon i5000_edac ppdev iTCO_wdt iTCO_vendor_support edac_core parport_pc dca mdio i2c_i801 parport floppy pcspkr shpchp ata_generic pata_acpi radeon ttm drm i2c_algo_bit i2c_core [last unloaded: aoe] Pid: 21300, comm: umount Tainted: G D 2.6.31 #1 Call Trace: [] warn_slowpath_common+0x8d/0xbb [] warn_slowpath_null+0x27/0x3d [] do_exit+0x54/0x6da [] oops_end+0xc8/0xe7 [] die+0x6d/0x8c [] do_trap+0x124/0x147 [] ? atomic_notifier_call_chain+0x26/0x3c [] do_invalid_op+0xa9/0xc9 [] ? xfs_log_move_tail+0x34/0x174 [xfs] [] ? trace_hardirqs_off_thunk+0x3a/0x6c [] invalid_op+0x1b/0x20 [] ? xfs_log_move_tail+0x34/0x174 [xfs] [] xfs_trans_ail_delete+0x82/0xf4 [xfs] [] xfs_buf_iodone+0x40/0x63 [xfs] [] xfs_buf_do_callbacks+0x3c/0x5f [xfs] [] xfs_buf_iodone_callbacks+0x136/0x175 [xfs] [] xfs_buf_iodone_work+0x63/0x86 [xfs] [] xfs_buf_ioend+0x93/0xb7 [xfs] [] xfs_bioerror+0x56/0x76 [xfs] [] xfs_bdstrat_cb+0x48/0x67 [xfs] [] xfs_buf_iostrategy+0x2a/0x47 [xfs] [] xfs_flush_buftarg+0xa1/0x125 [xfs] [] xfs_free_buftarg+0x32/0x8f [xfs] [] xfs_close_devices+0x77/0x94 [xfs] [] xfs_fs_put_super+0xb1/0xe8 [xfs] [] generic_shutdown_super+0x69/0xf2 [] kill_block_super+0x3a/0x6a [] deactivate_super+0x68/0x95 [] mntput_no_expire+0xc6/0x114 [] sys_umount+0x2f2/0x337 [] system_call_fastpath+0x16/0x1b ---[ end trace 838ac7bc7c8a18c9 ]--- [root@stuart srrd]# -- Ed Cashin Find experimental aoe Linux driver patches at http://coraid.typepad.com/aoe_linux_proving_grounds/ From BATV+bc23c2b8cc6a951fe7f0+2269+infradead.org+hch@bombadil.srs.infradead.org Mon Nov 9 15:05:05 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA9L53wx224119 for ; Mon, 9 Nov 2009 15:05:05 -0600 X-ASG-Debug-ID: 1257800720-604c00770000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 39C3170F99 for ; Mon, 9 Nov 2009 13:05:20 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 5AR1sOwdGdxwAGWI for ; Mon, 09 Nov 2009 13:05:20 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1N7bQN-0003Ad-Fb; Mon, 09 Nov 2009 21:05:19 +0000 Date: Mon, 9 Nov 2009 16:05:19 -0500 From: Christoph Hellwig To: Ed Cashin Cc: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: NULL mp->m_log in 2.6.31 xfs_log_move_tail Subject: Re: NULL mp->m_log in 2.6.31 xfs_log_move_tail Message-ID: <20091109210519.GA9698@infradead.org> References: <87ws1z8mbf.fsf@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ws1z8mbf.fsf@coraid.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1257800721 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 09, 2009 at 03:39:32PM -0500, Ed Cashin wrote: > A colleague has seen oopses in 2.6.31 when an XFS is mounted on an AoE > target that becomes unresponsive and is marked as "down" by the aoe > driver. The aoe driver starts failing all new I/O requests after > failing all current requests when the device is down. And the oops happens when unmounting the devices? That's at least how the trace looks like. If that's the case I suspect we tear down the log a bit too early - I'll do an audit of the log shutdown path how this could happen. From BATV+bc23c2b8cc6a951fe7f0+2269+infradead.org+hch@bombadil.srs.infradead.org Mon Nov 9 15:16:03 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA9LG3hR224550 for ; Mon, 9 Nov 2009 15:16:03 -0600 X-ASG-Debug-ID: 1257801380-5b57012d0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F3C3471202 for ; Mon, 9 Nov 2009 13:16:20 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id M0V4boa9YqwzgIcx for ; Mon, 09 Nov 2009 13:16:20 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1N7bb2-000663-MT; Mon, 09 Nov 2009 21:16:20 +0000 Date: Mon, 9 Nov 2009 16:16:20 -0500 From: Christoph Hellwig To: Ed Cashin Cc: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: NULL mp->m_log in 2.6.31 xfs_log_move_tail Subject: Re: NULL mp->m_log in 2.6.31 xfs_log_move_tail Message-ID: <20091109211620.GA22777@infradead.org> References: <87ws1z8mbf.fsf@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ws1z8mbf.fsf@coraid.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1257801380 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 09, 2009 at 03:39:32PM -0500, Ed Cashin wrote: > A colleague has seen oopses in 2.6.31 when an XFS is mounted on an AoE > target that becomes unresponsive and is marked as "down" by the aoe > driver. The aoe driver starts failing all new I/O requests after > failing all current requests when the device is down. > > I looked at the trace (included below) and put in the following check: Given that you seem to be able to reproduce it can you see if the patch below helps: Index: linux-2.6/fs/xfs/xfs_log.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_log.c 2009-11-09 22:09:08.858026060 +0100 +++ linux-2.6/fs/xfs/xfs_log.c 2009-11-09 22:13:13.958255857 +0100 @@ -1602,6 +1602,8 @@ xlog_dealloc_log(xlog_t *log) xlog_in_core_t *iclog, *next_iclog; int i; + xfs_flush_buftarg(log->l_mp->m_logdev_targp, 1); + iclog = log->l_iclog; for (i=0; il_iclog_bufs; i++) { sv_destroy(&iclog->ic_force_wait); From sgi-linux-xfs@lo.gmane.org Mon Nov 9 15:42:12 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nA9LgBDS225565 for ; Mon, 9 Nov 2009 15:42:11 -0600 X-ASG-Debug-ID: 1257802947-6bef01920000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lo.gmane.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 71F0F70BB6 for ; Mon, 9 Nov 2009 13:42:27 -0800 (PST) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by cuda.sgi.com with ESMTP id PGzDOI9TOJ3Xmbet for ; Mon, 09 Nov 2009 13:42:27 -0800 (PST) Received: from list by lo.gmane.org with local (Exim 4.50) id 1N7c0C-000808-VQ for linux-xfs@oss.sgi.com; Mon, 09 Nov 2009 22:42:20 +0100 Received: from adsl-068-016-104-079.sip.asm.bellsouth.net ([68.16.104.79]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Nov 2009 22:42:20 +0100 Received: from ecashin by adsl-068-016-104-079.sip.asm.bellsouth.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Nov 2009 22:42:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Ed Cashin X-ASG-Orig-Subj: Re: NULL mp->m_log in 2.6.31 xfs_log_move_tail Subject: Re: NULL mp->m_log in 2.6.31 xfs_log_move_tail Date: Mon, 09 Nov 2009 16:41:58 -0500 Lines: 36 Message-ID: <87fx8n8jfd.fsf@coraid.com> References: <87ws1z8mbf.fsf@coraid.com> <20091109211620.GA22777@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org Cc: ecashin@coraid.com X-Gmane-NNTP-Posting-Host: adsl-068-016-104-079.sip.asm.bellsouth.net User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:r/vqIqPDbxJrkW6NI1hmHa/KbwI= Sender: news X-Barracuda-Connect: lo.gmane.org[80.91.229.12] X-Barracuda-Start-Time: 1257802948 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Christoph Hellwig writes: > On Mon, Nov 09, 2009 at 03:39:32PM -0500, Ed Cashin wrote: >> A colleague has seen oopses in 2.6.31 when an XFS is mounted on an AoE >> target that becomes unresponsive and is marked as "down" by the aoe >> driver. The aoe driver starts failing all new I/O requests after >> failing all current requests when the device is down. >> >> I looked at the trace (included below) and put in the following check: > > Given that you seem to be able to reproduce it can you see if the patch > below helps: > > Index: linux-2.6/fs/xfs/xfs_log.c > =================================================================== > --- linux-2.6.orig/fs/xfs/xfs_log.c 2009-11-09 22:09:08.858026060 +0100 > +++ linux-2.6/fs/xfs/xfs_log.c 2009-11-09 22:13:13.958255857 +0100 > @@ -1602,6 +1602,8 @@ xlog_dealloc_log(xlog_t *log) > xlog_in_core_t *iclog, *next_iclog; > int i; > > + xfs_flush_buftarg(log->l_mp->m_logdev_targp, 1); > + > iclog = log->l_iclog; > for (i=0; il_iclog_bufs; i++) { > sv_destroy(&iclog->ic_force_wait); > Thanks. I am not sure when we'll be able to try it, because the one who discovered this issue is not currently available, but I'll try to fit it in one way or another. A lot of folks using AoE use XFS. -- Ed Cashin http://www.coraid.com/ http://noserose.net/e/ From cattelan@thebarn.com Mon Nov 9 19:25:35 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAA1PZsh235304 for ; Mon, 9 Nov 2009 19:25:35 -0600 X-ASG-Debug-ID: 1257816351-4b9b01780000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from x.digitalelves.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D28DA71B06 for ; Mon, 9 Nov 2009 17:25:51 -0800 (PST) Received: from x.digitalelves.com (v-209-98-77-55.ip.visi.com [209.98.77.55]) by cuda.sgi.com with ESMTP id zRJrlNYN6RFAscXU for ; Mon, 09 Nov 2009 17:25:51 -0800 (PST) Received: from strip.x.thebarn.com (localhost [IPv6:::1]) (authenticated bits=0) by x.digitalelves.com (8.14.3/8.14.3) with ESMTP id nAA1PiZp037155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 19:25:49 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <4AF8C118.5080903@thebarn.com> Date: Mon, 09 Nov 2009 19:25:44 -0600 From: Russell Cattelan User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: mill / in-medias-res CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair breaks; xfs_metadump hangs Subject: Re: xfs_repair breaks; xfs_metadump hangs References: <20091104152022.GA21347@mytux.intra.in-medias-res.com> <4AF4A66B.8090906@digitalelves.com> <20091109091915.GB3601@mytux.intra.in-medias-res.com> <20091109095126.GA9727@mytux.intra.in-medias-res.com> In-Reply-To: <20091109095126.GA9727@mytux.intra.in-medias-res.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------010209000806090502080506" X-Barracuda-Connect: v-209-98-77-55.ip.visi.com[209.98.77.55] X-Barracuda-Start-Time: 1257816351 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14206 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This is a multi-part message in MIME format. --------------010209000806090502080506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mill / in-medias-res wrote: > * mill / in-medias-res [091109 10:28]: >>> Hmm interesting. >>> Can you go into xfs_db and print out the bad inode? send it to us? >>> I'm guessing the extents are corrupted somehow. >> Did you mean "xfs_db -x -c 'blockget inode 3256930831' /dev/sdc2" ? >> xfs_db consumes 99% of CPU and Virt 2510m RES 194m of RAM. >> >> How long should i wait? I was thinking just the inode xfs_db -x -c 'inode 3256930831' -c 'p' /dev/sdc2 >> > Done now: > xfs_db -x -c 'blockget inode 3256930831' /dev/sdc2 > xfs_db.log :( > exit code 3 > 338,12s user 12,32s system 49% cpu 11:48,39 total > The first lines of output: > bad number of extents 1 for inode 3256930831 > bad nblocks 1 for inode 3256930831, counted 0 > block 9/2317591 type unknown not expected > link count mismatch for inode 1038934 (name ?), nlink 1, counted 2 > link count mismatch for inode 128 (name ?), nlink 4672, counted 6 > link count mismatch for inode 129 (name ?), nlink 36525, counted 1 > link count mismatch for inode 130 (name ?), nlink 0, counted 1 > link count mismatch for inode 131 (name ?), nlink 0, counted 1 > link count mismatch for inode 132 (name ?), nlink 2, counted 1305238 > link count mismatch for inode 133 (name ?), nlink 0, counted 2 > link count mismatch for inode 134 (name ?), nlink 7144, counted 1 > link count mismatch for inode 135 (name ?), nlink 42666, counted 1 > link count mismatch for inode 136 (name ?), nlink 40424, counted 2 > link count mismatch for inode 137 (name ?), nlink 37040, counted 2 > link count mismatch for inode 138 (name ?), nlink 16, counted 2 > link count mismatch for inode 139 (name ?), nlink 0, counted 2 > link count mismatch for inode 140 (name ?), nlink 20, counted 2 > link count mismatch for inode 141 (name ?), nlink 0, counted 2 > link count mismatch for inode 142 (name ?), nlink 12, counted 2 > link count mismatch for inode 143 (name ?), nlink 62336, counted 2 > link count mismatch for inode 144 (name ?), nlink 3203, counted 2 > link count mismatch for inode 146 (name ?), nlink 27224, counted 2 > link count mismatch for inode 147 (name ?), nlink 41204, counted 2 > link count mismatch for inode 148 (name ?), nlink 21, counted 2 > link count mismatch for inode 149 (name ?), nlink 0, counted 2 > link count mismatch for inode 150 (name ?), nlink 0, counted 2 > link count mismatch for inode 151 (name ?), nlink 0, counted 2 > link count mismatch for inode 152 (name ?), nlink 0, counted 2 > link count mismatch for inode 153 (name ?), nlink 32768, counted 2 > link count mismatch for inode 154 (name ?), nlink 58352, counted 2 > link count mismatch for inode 155 (name ?), nlink 40290, counted 2 > The output is 53 MB big. Tons of link count mismatch for inode ... Hmm that is not a good sign. That would suggest a big chunk of inodes go corrupted. I might be working looking at a few of the inodes and see if any pattern shows up. > > >>> One option to then flag the inode as deleted which will cause repair to >>> toss is hopefully clean up the mess. >>> >>> Here is a write up how to do that. >>> http://jijo.free.net.ph/19 >> If i can't get that block i will try with deleting it, Thanks! >> >> Best regards, >> Maximilian Mill >>>> time: 67,27s user 10,09s system 10% cpu 12:05,31 total >>>> >>>> I tried to run xfs_metadump serveral times and it hangs everytime on this position: >>>> xfs_metadump -g /dev/sdc2 metadump-sdc2-2 >>>> Copied 1411840 of 4835520 inodes (0 of 3 AGs) >>>> >>>> It runs till 2 days on the same inode and xfs_db consumes 99% of CPU. >>>> Should i wait here? >>>> >>>> Versions: >>>> dpkg -l |grep xfs >>>> ii xfsdump 3.0.2~bpo50+1 Administrative utilities for the XFS filesys >>>> ii xfsprogs 3.0.4~bpo50+1 Utilities for managing the XFS filesystem >>>> Distribution: Debian lenny with xfsprogs, xfsdump backport from unstable. >>>> >>>> The xfs_repair with stock Debian Lenny version also does crash at inode 3256930831. >>>> >>>> Best Regards, >>>> Maximilian Mill >>>> >>>> _______________________________________________ >>>> xfs mailing list >>>> xfs@oss.sgi.com >>>> http://oss.sgi.com/mailman/listinfo/xfs >>>> >>>> >>> >> _______________________________________________ >> xfs mailing list >> xfs@oss.sgi.com >> http://oss.sgi.com/mailman/listinfo/xfs >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4wRcACgkQNRmM+OaGhBiOEQCfTiGW5yBzo4mKL6LJlWMPhrCM F3gAn2MbX5E1RpO1wOQ08ZOxSFq3QoNi =fVoe -----END PGP SIGNATURE----- --------------010209000806090502080506 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 tel;cell:612 805 3144 x-mozilla-html:FALSE version:2.1 end:vcard --------------010209000806090502080506-- From info@pushbuttonemailer2.com Tue Nov 10 00:16:13 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAA6GDlB253188 for ; Tue, 10 Nov 2009 00:16:13 -0600 X-ASG-Debug-ID: 1257833790-7dd802c30000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pushbuttonemailer2.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E4F93720C6 for ; Mon, 9 Nov 2009 22:16:30 -0800 (PST) Received: from pushbuttonemailer2.com (pushbuttonemailer2.com [208.43.204.98]) by cuda.sgi.com with ESMTP id vbOhKVJXhIkGdSjA for ; Mon, 09 Nov 2009 22:16:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=pushbuttonemailer2.com; h=Received:To:Subject:From:Reply-To:MIME-Version:X-Mailer:Content-Type:Content-Transfer-Encoding:Message-Id:Date; b=tWU5bHdjlnarRC6psRrLp8SUw/JCvTFXi2LoOZZf21lR/KW1XZRudviXAbkFKpSqEiC5gt47lUlHIOiTeMlD90+tU2fqMCX/sMc2IRYVBbNuUmFqjveX425GSwnH8nVm; Received: from billp2 by plate.arvixe.com with local (Exim 4.69) (envelope-from ) id 1N7k1l-0002Ut-RP for linux-xfs@oss.sgi.com; Mon, 09 Nov 2009 22:16:29 -0800 To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Push Button Emailer Subject: Push Button Emailer From: Bill Phillips Reply-To: MIME-Version: 1.0 X-Mailer: GMailer 1.2 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Date: Mon, 09 Nov 2009 22:16:29 -0800 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - plate.arvixe.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [585 585] / [47 12] X-AntiAbuse: Sender Address Domain - pushbuttonemailer2.com X-Barracuda-Connect: pushbuttonemailer2.com[208.43.204.98] X-Barracuda-Start-Time: 1257833790 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5343 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.16 X-Barracuda-Spam-Status: No, SCORE=1.16 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14222 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Load Your List and Send Your Sales Message to 4,000 to 10,000 People EVERYDAY With The Push Of A Button!!!! • Load YOUR List • Write YOUR Message • Push A Button!!! 4,000 Emails Per Day... 120,000 Emails Per Month!!! 10,000 Emails Per Day...300,000 Emails Per Month!!! To be remove from our list, just reply with the word remove in the subject line. From sbshepherd@ymail.com Tue Nov 10 12:24:30 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE, UNPARSEABLE_RELAY autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAAIOTu9042647 for ; Tue, 10 Nov 2009 12:24:29 -0600 X-ASG-Debug-ID: 1257877485-4b0f004e0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp101.prem.mail.ac4.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id BB74DCFC8E8 for ; Tue, 10 Nov 2009 10:24:45 -0800 (PST) Received: from smtp101.prem.mail.ac4.yahoo.com (smtp101.prem.mail.ac4.yahoo.com [76.13.13.40]) by cuda.sgi.com with SMTP id viIC6usbkHYQgwH5 for ; Tue, 10 Nov 2009 10:24:45 -0800 (PST) Received: (qmail 76943 invoked from network); 10 Nov 2009 18:24:44 -0000 Received: from adsl-217-125-105.asm.bellsouth.net (sbshepherd@68.217.125.105 with login) by smtp101.prem.mail.ac4.yahoo.com with SMTP; 10 Nov 2009 10:24:43 -0800 PST X-Yahoo-SMTP: q_iQ9CGswBDWnfaDdDweA5p0bKjGVP7HPTihrghQ1G3J X-YMail-OSG: iIhuoRsVM1k.pN23nRM54c7zxaYj0C.QCn_ICDYtsv9gfE7wBGKPqYNY1ZvB4vaIKhFCtxQY84PDX0NLjJq5MU2R7zcUVDphIDY.ESiWodvy27wkqKJ4fAZjwd9VrHWGIJqqmcowYk_i4Lt.Z6qlmlr5cZ9UTZqwadZ0YIdkq6obaUXpu8455jK10JwclD5BH0.yffH12B.Ww9e.tfhb_y4K1L6ThgexduPXsUO1obxqwiOiDqUq.1ljB_yjDZpl3jrcJb1vgQ1rIDaLTp0dq6NIt51byFRmL43EkPcvylXHkeqYTYKkacO7gum6xCZWGydLpczk3w-- X-Yahoo-Newman-Property: ymail-3 From: "Scott Shepherd" To: X-ASG-Orig-Subj: EHS Document Management Made Simple for Less Subject: EHS Document Management Made Simple for Less Date: Tue, 10 Nov 2009 13:23:23 -0500 Message-ID: <0d5d01ca6232$feabcfc0$fc036f40$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D5E_01CA6209.15D5C7C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acph2G6Vhh72DrPoRsmRRO3cLVDfdA== Content-Language: en-us X-Barracuda-Connect: smtp101.prem.mail.ac4.yahoo.com[76.13.13.40] X-Barracuda-Start-Time: 1257877486 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14265 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean This is a multi-part message in MIME format. ------=_NextPart_000_0D5E_01CA6209.15D5C7C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EHS Professionals, Are you being asked to provide more MSDS support with less? Let us show you how. No software, no risk, just simple reliable MSDS management. Go to www.OnlineMSDS.com today for more info. We offer more features and benefits than any other comparable solution on the market at a lower price. Guaranteed. Our Online MSDS Solution is robust enough to handle the complexities of managing global MSDSs and related information in a secure environment as well as one that is also very simple, intuitive and user friendly. It will help you comply with all Hazcom regulations. Related product information such as videos, music and images can also be loaded and used for safety training, product demos, technical information, brochures, etc. Visit www.OnlineMSDS.com to learn how we can simplify your MSDS management for less today. Scott Shepherd, Manager IMTEK Environmental Corporation I www.OnlineMSDS.com sbshepherd@ymail.com I 770.335.5586 I o 770.667.8683 I Skype EnviroPro ---------------------------------------------------------------------------- ---------------------------------------------------------------- Sustainability & EHS Management Solutions Made Simple for Less ------=_NextPart_000_0D5E_01CA6209.15D5C7C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

EHS Professionals,

Are you being asked to provide more MSDS support with less? Let us show you = how. No software, no risk, just simple reliable MSDS management. Go to www.OnlineMSDS.com today for more info. We offer more features and benefits than any other comparable solution on the market at a lower = price. Guaranteed.

 

Our Online MSDS Solution is robust enough to handle the complexities of managing global = MSDSs and related information in a secure environment as well as one that is also = very simple, intuitive and user friendly. It will help you comply with all = Hazcom regulations.

 

Related product information such as videos, music and images can also be loaded = and used for safety training, product demos, technical information, = brochures, etc.

 

Visit www.OnlineMSDS.com to learn how we can simplify = your MSDS management for less today.

 

Scott Shepherd, Manager 

IMTEK Environmental Corporation I www.OnlineMSDS.com

sbshepherd@ymail.com I 770.335.5586 I o 770.667.8683 I Skype = EnviroPro

---------------------------------------------------------= -------------------------------------------------------------------------= ----------

Sustainability & EHS Management Solutions Made Simple for Less

 

------=_NextPart_000_0D5E_01CA6209.15D5C7C0-- From michael.monnerie@is.it-management.at Wed Nov 11 09:31:46 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nABFVisn149705 for ; Wed, 11 Nov 2009 09:31:46 -0600 X-ASG-Debug-ID: 1257953520-336703910000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1673ED09183 for ; Wed, 11 Nov 2009 07:32:00 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id xy9h38Y6d2gpKSVF for ; Wed, 11 Nov 2009 07:32:00 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id 9FE32C0047F for ; Wed, 11 Nov 2009 16:31:57 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 70D63400178 for ; Wed, 11 Nov 2009 16:31:57 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair question: "wrong" order of AG checks OK? Subject: xfs_repair question: "wrong" order of AG checks OK? Date: Wed, 11 Nov 2009 16:31:56 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911111631.56993@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257953522 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14345 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I did an xfs_repair now, and everything was OK. But strange was, in Phase 4 the AGs were not checked in order: AG 2 AG 1 AG 0 AG 3 AG 4 AG 5 Is that normal? mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From nscott@aconex.com Wed Nov 11 16:17:21 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nABMHLrC186248 for ; Wed, 11 Nov 2009 16:17:21 -0600 X-ASG-Debug-ID: 1257977858-42d102f90000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice2.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EA347185FAD1 for ; Wed, 11 Nov 2009 14:17:38 -0800 (PST) Received: from postoffice2.aconex.com (mail.aconex.com [203.89.202.182]) by cuda.sgi.com with ESMTP id u5giLS2UiXvh2Q08 for ; Wed, 11 Nov 2009 14:17:38 -0800 (PST) Received: from postoffice.aconex.com (localhost [127.0.0.1]) by postoffice2.aconex.com (Spam & Virus Firewall) with ESMTP id B0B5F86BAB7; Thu, 12 Nov 2009 09:17:36 +1100 (EST) Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.102.1]) by postoffice2.aconex.com with ESMTP id 3KDA83xVk6xToXxf; Thu, 12 Nov 2009 09:17:36 +1100 (EST) Received: from gatekeeper.aconex.com (gatekeeper.yarra.acx [192.168.102.10]) by postoffice.aconex.com (Postfix) with ESMTP id 4286BA50280; Thu, 12 Nov 2009 09:15:58 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by gatekeeper.aconex.com (Postfix) with ESMTP id 91B4CC7B99; Thu, 12 Nov 2009 09:17:36 +1100 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: amavisd-new at gatekeeper.yarra.acx Received: from gatekeeper.aconex.com ([127.0.0.1]) by localhost (gatekeeper.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uck3bwvmu3cL; Thu, 12 Nov 2009 09:17:31 +1100 (EST) Received: from mail-au.aconex.com (mail-au.aconex.com [192.168.102.12]) by gatekeeper.aconex.com (Postfix) with ESMTP id CF8DFC7A7B; Thu, 12 Nov 2009 09:17:31 +1100 (EST) Date: Thu, 12 Nov 2009 09:17:31 +1100 (EST) From: Nathan Scott To: Michael Monnerie Cc: linux-xfs@oss.sgi.com Message-ID: <475457384.356771257977851793.JavaMail.root@mail-au.aconex.com> In-Reply-To: <200911111631.56993@zmi.at> X-ASG-Orig-Subj: Re: xfs_repair question: "wrong" order of AG checks OK? Subject: Re: xfs_repair question: "wrong" order of AG checks OK? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [203.89.192.141] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraWebClient - [unknown] (Linux)/5.0.18_GA_3011.RHEL5_64) X-Barracuda-Connect: mail.aconex.com[203.89.202.182] X-Barracuda-Start-Time: 1257977859 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14371 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean ----- "Michael Monnerie" wrote: > I did an xfs_repair now, and everything was OK. But strange was, in > Phase 4 the AGs were not checked in order: > AG 2 > AG 1 > AG 0 > AG 3 > AG 4 > AG 5 > > Is that normal? Could be xfs_repair running with multiple threads in parallel? cheers. -- Nathan From michael.monnerie@is.it-management.at Wed Nov 11 17:29:09 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nABNT76J193137 for ; Wed, 11 Nov 2009 17:29:09 -0600 X-ASG-Debug-ID: 1257982163-59c301d30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 97870185FF69 for ; Wed, 11 Nov 2009 15:29:23 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id gB7G7MU8Dknufiq8 for ; Wed, 11 Nov 2009 15:29:23 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id 5E977C02731 for ; Thu, 12 Nov 2009 00:29:22 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 33FF0400178 for ; Thu, 12 Nov 2009 00:29:22 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair question: "wrong" order of AG checks OK? Subject: Re: xfs_repair question: "wrong" order of AG checks OK? Date: Thu, 12 Nov 2009 00:29:21 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <475457384.356771257977851793.JavaMail.root@mail-au.aconex.com> In-Reply-To: <475457384.356771257977851793.JavaMail.root@mail-au.aconex.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911120029.21845@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257982164 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14377 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mittwoch 11 November 2009 Nathan Scott wrote: > Could be xfs_repair running with multiple threads in parallel? Would it ever do that? There's no performance advantage in that, as that operation is disk I/O bound, isn't it? mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From nscott@aconex.com Wed Nov 11 18:22:52 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAC0MpE2198263 for ; Wed, 11 Nov 2009 18:22:51 -0600 X-ASG-Debug-ID: 1257985388-7cd401c40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice2.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 99B2E1860184 for ; Wed, 11 Nov 2009 16:23:09 -0800 (PST) Received: from postoffice2.aconex.com (mail.aconex.com [203.89.202.182]) by cuda.sgi.com with ESMTP id 7kY3G8IeRX4r7QRO for ; Wed, 11 Nov 2009 16:23:09 -0800 (PST) Received: from postoffice.aconex.com (localhost [127.0.0.1]) by postoffice2.aconex.com (Spam & Virus Firewall) with ESMTP id A50DA5BD606; Thu, 12 Nov 2009 11:23:07 +1100 (EST) Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.102.1]) by postoffice2.aconex.com with ESMTP id wkwx1PHz1DGsEpJa; Thu, 12 Nov 2009 11:23:07 +1100 (EST) Received: from gatekeeper.aconex.com (gatekeeper.yarra.acx [192.168.102.10]) by postoffice.aconex.com (Postfix) with ESMTP id 0BC9DA50280; Thu, 12 Nov 2009 11:21:29 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by gatekeeper.aconex.com (Postfix) with ESMTP id 73C944FD84; Thu, 12 Nov 2009 11:23:07 +1100 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: amavisd-new at gatekeeper.yarra.acx Received: from gatekeeper.aconex.com ([127.0.0.1]) by localhost (gatekeeper.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH0jq+PewJUq; Thu, 12 Nov 2009 11:23:03 +1100 (EST) Received: from mail-au.aconex.com (mail-au.aconex.com [192.168.102.12]) by gatekeeper.aconex.com (Postfix) with ESMTP id 607B64FD82; Thu, 12 Nov 2009 11:23:03 +1100 (EST) Date: Thu, 12 Nov 2009 11:23:03 +1100 (EST) From: Nathan Scott To: Michael Monnerie Cc: xfs@oss.sgi.com Message-ID: <1047569616.363721257985383289.JavaMail.root@mail-au.aconex.com> In-Reply-To: <200911120029.21845@zmi.at> X-ASG-Orig-Subj: Re: xfs_repair question: "wrong" order of AG checks OK? Subject: Re: xfs_repair question: "wrong" order of AG checks OK? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [203.89.192.141] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraWebClient - [unknown] (Linux)/5.0.18_GA_3011.RHEL5_64) X-Barracuda-Connect: mail.aconex.com[203.89.202.182] X-Barracuda-Start-Time: 1257985389 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14380 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Status: Clean ----- "Michael Monnerie" wrote: > On Mittwoch 11 November 2009 Nathan Scott wrote: > > Could be xfs_repair running with multiple threads in parallel? > > Would it ever do that? There's no performance advantage in that, as > that operation is disk I/O bound, isn't it? Be worth reading the paper here: http://xfs.org/index.php/XFS_Papers_and_Documentation -> "Fixing XFS Filesystems Faster" cheers. -- Nathan From michael.monnerie@is.it-management.at Wed Nov 11 18:51:57 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAC0pv5l200924 for ; Wed, 11 Nov 2009 18:51:57 -0600 X-ASG-Debug-ID: 1257987134-11ba02170000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv1.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7CFC57C06B for ; Wed, 11 Nov 2009 16:52:14 -0800 (PST) Received: from mailsrv1.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id LiGAlraEMjgVsp6u for ; Wed, 11 Nov 2009 16:52:14 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv1.zmi.at (Postfix) with ESMTP id 27ED4C02731 for ; Thu, 12 Nov 2009 01:52:12 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id D204C400178 for ; Thu, 12 Nov 2009 01:52:11 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair question: "wrong" order of AG checks OK? Subject: Re: xfs_repair question: "wrong" order of AG checks OK? Date: Thu, 12 Nov 2009 01:52:10 +0100 User-Agent: KMail/1.10.3 (Linux/2.6.31.4-ZMI; KDE/4.1.3; x86_64; ; ) References: <1047569616.363721257985383289.JavaMail.root@mail-au.aconex.com> In-Reply-To: <1047569616.363721257985383289.JavaMail.root@mail-au.aconex.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200911120152.11201@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1257987135 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14382 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Donnerstag 12 November 2009 Nathan Scott wrote: > http://xfs.org/index.php/XFS_Papers_and_Documentation > =A0 =A0-> "Fixing XFS Filesystems Faster" Quite a fun to read, especially the comparison with ext3. Thanks for the link. mfg zmi =2D-=20 // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4 From xfs@tlinx.org Wed Nov 11 20:38:21 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAC2cKu9210316 for ; Wed, 11 Nov 2009 20:38:20 -0600 X-ASG-Debug-ID: 1257993518-7cc901420000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from Ishtar.sc.tlinx.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 52BA2D12D71 for ; Wed, 11 Nov 2009 18:38:38 -0800 (PST) Received: from Ishtar.sc.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by cuda.sgi.com with ESMTP id fZTqOafCcctkSIkK for ; Wed, 11 Nov 2009 18:38:38 -0800 (PST) Received: from [192.168.3.11] (Athena [192.168.3.11]) by Ishtar.sc.tlinx.org (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAC2cZbQ002047 for ; Wed, 11 Nov 2009 18:38:37 -0800 Message-ID: <4AFB752F.2080307@tlinx.org> Date: Wed, 11 Nov 2009 18:38:39 -0800 From: "Linda A. Walsh" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22) Gecko/20090605 Lightning/0.9 Thunderbird/2.0.0.22 ThunderBrowse/3.2.6.5 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: xfsdump/restore? Performance ... Subject: xfsdump/restore? Performance ... X-Stationery: 0.4.10 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ishtar.tlinx.org[64.81.245.74] X-Barracuda-Start-Time: 1257993518 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14389 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dunno if xfsdump/restore are considered that important with bacula being adverted as being xfs-compat, but something I found that speeds up and xfsdump/restore, or, especially, using xfsdump/restore to copy a file system -- I put 'mbuffer' in between them and gave it 1mb buffers, and used about 1024 of them. My fs->fs copy rate went up by 50%. An equivalent amount of data took about 2700++ seconds with direction pipe from xfsdump|xfsrestore, but with a buffer between them, that dropped to about 1800+. Maybe xfsdump/restore need some larger buffers? I was also thinking -- I'm not sure how xfsrestore restores files, but does it take each file as it comes, and then restores it, or does it cache the handles to the directories in the previous path? Usually wouldn't be noticeable, but if it has to walk through directories that have lots of files, might save some lookup time. If both were multithreaded -- with one thread for buffer management while the other could do disk I/O -- or is that the infamous '-Y' option that has yet to be implemented on linux? :-) Don't know how much interest there is in these utils, but thought I'd mention the benefit of a big buffer... Same goes for restore and dump I presume, separately. I.e. if xfsdump always does output to mbuffer and mbuffer writes to disk or to Xzip (X=g,bz,lz). Maybe write's are sufficiently well buffered by the kernel, that only restores would benefit -- with mbuffer reading a backup file, but if those utils are used, there are some good possibilities for performance improvements... -linda From c3woutso@serv01.siteground169.com Wed Nov 11 22:59:54 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAC4xqCn221659 for ; Wed, 11 Nov 2009 22:59:52 -0600 X-ASG-Debug-ID: 1258002009-48d003740000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from serv01.siteground169.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6E1491860C37 for ; Wed, 11 Nov 2009 21:00:10 -0800 (PST) Received: from serv01.siteground169.com (ns1.siteground169.com [67.15.211.9]) by cuda.sgi.com with ESMTP id WedTCD3TxnqIK5fr for ; Wed, 11 Nov 2009 21:00:10 -0800 (PST) Received: from localhost ([127.0.0.1]:35980 helo=serv01.siteground169.com) by serv01.siteground169.com with smtp (Exim 4.69) (envelope-from ) id 1N8Rmz-0004Ty-I9 for linux-xfs@oss.sgi.com; Wed, 11 Nov 2009 23:00:09 -0600 To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: software / web development Subject: software / web development Recieved: Date: Wed, 11 Nov 2009 23:00:09 -0600 From: 3W-Outsource|Sunita Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] X-Mailer: phplist v2.10.10 X-MessageID: 6 X-ListMember: linux-xfs@oss.sgi.com Precedence: bulk MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - serv01.siteground169.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - serv01.siteground169.com X-Barracuda-Connect: ns1.siteground169.com[67.15.211.9] X-Barracuda-Start-Time: 1258002010 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4921 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14398 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean **Hello** I am Sunita From India. Are you looking for software development desktop/web application/web design or outsourcing your work load in software development?? then we are the best solution for it. *Key Benefits in our relations.* We use only highly skilled and experienced developers. We can handle projects of any size or complexity. All of our developers have a minimum of 5 years of experience in programming. We have a portfolio of existing UK companies and understand how they operate. * Kind Regards Sunita Marketing Director 3w-outsource A-4 Vidyva Vihar Padmnabhpur Durg Chhattisgarh India +917882344623 * Email: sunita@3w-outsource.com Website: http://www.3w-outsource.com -- If you do not want to receive any more Emails, http://3w-outsource.com/sendemail/?p=unsubscribe&uid=779dcd1e2bc4a728d3745f939e69175f Forward a Message to Someone http://3w-outsource.com/sendemail/?p=forward&uid=779dcd1e2bc4a728d3745f939e69175f&mid=6 -- Powered by PHPlist, www.phplist.com -- From press.club.international@gmail.com Thu Nov 12 00:13:22 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,RCVD_IN_BSP_OTHER autolearn=ham version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAC6DM4o228397 for ; Thu, 12 Nov 2009 00:13:22 -0600 X-ASG-Debug-ID: 1258006420-130b01990000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from vmta22.birthdayalarm.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C0ACA7B33A for ; Wed, 11 Nov 2009 22:13:40 -0800 (PST) Received: from vmta22.birthdayalarm.com (vmta22.birthdayalarm.com [38.99.45.42]) by cuda.sgi.com with ESMTP id amgycOiTCVFh0CYU for ; Wed, 11 Nov 2009 22:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dk; d=birthdayalarm.com; h=Date:From:Sender:To:Message-ID:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; i=service@noreply.BirthdayAlarm.com; bh=Wuw3u6deHOoltenLG4OkRfpX+I0=; b=HV2Bdndp52R2Z/CKS8UPqm02AM7/E8dK3eeoN6C2VfyrUocLsdy6k8JlW8e2ATVZ06wfSP3zDTK6 i9YJYKXXmBolrtcRJpp03xRyIfptrpTCOuhJTm9isDJY7yi0uHHImfOa1So5k/DZQYwSlfJe8u7a ebfHDh9ivW8qVShrQjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=dk; d=birthdayalarm.com; b=evz12ZXO5/cY+lpM/u3TDpwXMzRP4PGiSMUkhVrmkLt2F6PHPatt2PsRj8rGPM4ENZs+X8rq9Q05 jAFugXxTV1yWuGEnHLhff0l2Jt/M8m8siPVNCxi7YzqpSOMnwpvgSssQhz4y9p90jP/qn78By7ZH Apz/klsBHgYQEUK0pFo=; Received: by vmta22.birthdayalarm.com id hvejps0im3o9 for ; Thu, 12 Nov 2009 06:13:50 +0000 (envelope-from ) Date: Thu, 12 Nov 2009 06:14:18 +0000 (UTC) From: Asha Anu Sender: "service@noreply.BirthdayAlarm.com" To: xfs@oss.sgi.com Message-ID: <939431648.6376351258006458548.JavaMail.batch@lpc04> X-ASG-Orig-Subj: Updating my calendar Subject: Updating my calendar MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Email-Type: E067 X-Barracuda-Connect: vmta22.birthdayalarm.com[38.99.45.42] X-Barracuda-Start-Time: 1258006420 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5997 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14402 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi Kindly click on: http://www.birthdayalarm.com/bd2/85853215a308707420b1483972789c475320931d1386 Yours sincerely, Customer Support Team Spell check test: PRESSURE ON MAOS SON TO EXPLAIN THE LIVE Tv LINK From sandy@crosshandstraining.org.uk Thu Nov 12 02:10:28 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.5 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_8BIT_HEADER,URIBL_BLACK autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nAC8ARAY234720 for ; Thu, 12 Nov 2009 02:10:28 -0600 X-ASG-Debug-ID: 1258013444-7a5700640000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from DS4386.ds4386.dedicated.turbodns.co.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 577297CD49 for ; Thu, 12 Nov 2009 00:10:44 -0800 (PST) Received: from DS4386.ds4386.dedicated.turbodns.co.uk (server4386.dedicated.webfusion.co.uk [212.241.182.110]) by cuda.sgi.com with ESMTP id 8rWkyRBuUClOxHzf for ; Thu, 12 Nov 2009 00:10:44 -0800 (PST) Received: from host81-139-82-253.in-addr.btopenworld.com ([81.139.82.253]) by ds4386.dedicated.turbodns.co.uk with MailEnable ESMTP; Thu, 12 Nov 2009 07:54:52 +0000 From: "Sandra Keating" X-ASG-Orig-Subj: =?ISO-8859-1?B?ozk5IHAucC4gZm9yIHByYWN0aWNhbCAmIGVmZmVjdGl2ZSB0cmFpbmluZw==?= Subject: =?ISO-8859-1?B?ozk5IHAucC4gZm9yIHByYWN0aWNhbCAmIGVmZmVjdGl2ZSB0cmFpbmluZw==?= X-Direct-Mail-Bounce: X21WW0ZX-V7W9-4699-Z34Z-294U355V447U; xfs@oss.sgi.com Message-id: <1D4D4153-9C96-4BD0-8FBC-5977396E53B6@crosshandstraining.org.uk> MIME-Version: 1.0 Date: Thu, 12 Nov 2009 07:54:34 +0000 To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=Direct-Mail-MIME-Boundary-2 X-Barracuda-Connect: server4386.dedicated.webfusion.co.uk[212.241.182.110] X-Barracuda-Start-Time: 1258013445 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2791 1.0000 -0.4395 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.56 X-Barracuda-Spam-Status: No, SCORE=1.56 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC7_SA_HREF_WWW_MISMATCH, BSF_SC7_SA_SUB_MISMATCH_FR, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.14410 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.50 BSF_SC7_SA_SUB_MISMATCH_FR BODY: Custom Phishing Mismatch 0.50 BSF_SC7_SA_HREF_WWW_MISMATCH BODY: Custom Phishing Mismatch 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --Direct-Mail-MIME-Boundary-2 Content-Type: text/plain; format=flowed; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hello We have some last minute places available on these one-day training courses= running before Christmas, starting from =A399 p.p.=A0 We have trained over 10,000 individuals in the past 10 years. Nearly 1,000 = organisations consider us to be their trainer of choice, because we consist= ently offer affordable, practical and effective training, with observable a= nd measurable outcomes. You can book=A0securely online at www.crosshandstraining.org.uk or if you p= refer,=A0 by telephone on 01584 890970, or by email to bookings=40crosshand= straining.org.uk. All of our workshops run from 10am to 4.30pm and our venu= es are centrally located. We can also deliver any of our training on-site i= f you have a group of people and want to save on travel and accommodation c= osts. Facilitation Skills - Birmingham, 17th November; London, 18th November This workshop is aimed at delegates who are responsible for facilitating a = group of people. It is ideal for those who want practical tips on how to de= al with groups and the way in which they interact, on how to maximise a gro= up=92s potential and the right tools to use to generate and evaluate ideas = within a group and help the decision making process and to design and manag= e team and project reviews. Public Speaking & PowerPoint Presentations - Birmingham, 17th November This workshop is aimed at delegates who are interested in the theories and = practices of communication, as well as emotional responses to speaking in p= ublic, and who want to develop these, and their PowerPoint presentation ski= lls. The workshop will provide ample opportunities for participants to rese= arch topics of their own choosing and to practice effective public speaking= and to develop an engaging and interesting PowerPoint presentation to acco= mpany their speech. Delegates are asked to bring along a brief =5Bno more t= han 10 minutes=5D presentation which has been recently used. Each delegate = will be given an opportunity to present this to the group, whereupon feedba= ck will be given and practical ways in which to improve. This may take the = form of help with your slides, your presentation technique, or simply ideas= to help you create a slicker, more effective presentation.=A0 Writing Press Releases - London, 19th November This is an ideal training course for those who want to use press releases a= s a technique for publicising an event or calling attention to an issue. Th= roughout the workshop delegates will develop the skills to produce a well-w= ritten, well-distributed and well-timed press release, and to appreciate th= at it is not difficult or expensive to produce, yet can be effective and us= eful. The key to writing an effective press release is getting it read and = the information published. With these objectives in mind, this module is de= signed to equip delegates with the most important elements of the press rel= ease, which are a clear and engaging text, careful selection of recipients,= and good timing of release. Effective Training Skills - train the trainer - Geneva, 1st December This workshop is ideal for those who are required to effectively train empl= oyees, colleagues or clients in an interesting, engaging and confident mann= er, in a way that is practical and which will help delegates to gain new sk= ills, knowledge and understanding. Crisis Communication & Media Management Strategies - Geneva, 1st December This workshop combines advanced media skills with crisis communication tact= ics and is aimed at those at the highest level within the organisation who = will already have significant experience in dealing with the media. By the = end of the workshop the following areas will be covered, through practical = activities and individual endeavour: - a better awareness of media communic= ation problems and good practice; familiarity with the latest organisationa= l communication systems; demonstrating good practice in handling real probl= ems with media; how to develop media strategies for prevention; how to mana= ge high profile media events and crises and how to handle bad news/adverse = publicity. Media Strategies & Campaigns - Geneva, 2nd December This workshop is aimed at individuals and organisations who want to get the= media working for them and with them.=A0 Working with the media is an effe= ctive way to influence attitudes and opinions about your programme, issue o= r product. In this workshop we aim to help you develop and manage a media r= elations campaign, which is one of the most effective ways to reach your ta= rget audience. This workshop is ideal if you or your colleagues have a camp= aign to run or a new product to launch and you would like to harness the me= dia to full effect. Team Building & Group Dynamics - Geneva, 2nd December This workshop is aimed at those of who are responsible for a group of peopl= e and you want some practical tips on how to deal with conflict resolution,= anger management, team building and relationships within the group. If you= need the skills to get your group working better together, then this works= hop is an excellent way to start the ball rolling. Presentation & Communication Skills - Geneva, 4th December Individuals and organisations who want to improve the way they present and = communicate - both formally and informally - for effectiveness and profitab= ility.=A0 Through the use of group work and individual activities, this wor= kshop provides every participant with an opportunity to practice the techni= ques and skills needed to prepare and deliver a great presentation, and int= roduces the wide number of sources of noise or interference that can enter = into the communication process. Kind regards, Sales & Marketing Team, www.crosshandstraining.org.uk crosshands ltd, coreley, shropshire sy8 3ar, t: 01584 890970; incorporated = in england & wales. company registration: 3136393 VAT registration: 682 112= 6 51 You have been sent this mail because we understand that you wish to receive= information about our training services, however, if this is incorrect, or= you no longer wish to receive mail, please email remove=40crosshandstraini= ng.org.uk and your details will be removed immediately. =A0 =A0 =A0 =A0 --Direct-Mail-MIME-Boundary-2 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
H= ello
W= e have some last minute places available on these one-day training courses = running before Christmas, starting from &=23xa3;99 p.p.&=23xa0;
W= e have trained over 10,000 individuals in the past 10 years. Nearly 1,000 o= rganisations consider us to be their trainer of choice, because we consiste= ntly offer affordable, practical and effective training, with observable an= d measurable outcomes. 
Y= ou can book&=23xa0;securely online at ww= w.crosshandstraining.org.uk or if you prefer,&=23xa0; by telephone on 0= 1584 890970, or by email to bookings=40crosshandstraining.org.uk. All of our workshops= run from 10am to 4.30pm and our venues are centrally located. We can also = deliver any of our training on-site if you have a group of people and want = to save on travel and accommodation costs.
<= b>Facilitation Skills - Birmingham, 17th November; London, 18th Novembe= r
T= his workshop is aimed at delegates who are responsible for facilitating a g= roup of people. It is ideal for those who want practical tips on how to dea= l with groups and the way in which they interact, on how to maximise a grou= p&=23x2019;s potential and the right tools to use to generate and evaluate = ideas within a group and help the decision making process and to design and= manage team and project reviews.
<= b>Public Speaking & PowerPoint Presentations - Birmingham, 17th Nov= ember
T= his workshop is aimed at delegates who are interested in the theories and p= ractices of communication, as well as emotional responses to speaking in pu= blic, and who want to develop these, and their PowerPoint presentation skil= ls. The workshop will provide ample opportunities for participants to resea= rch topics of their own choosing and to practice effective public speaking = and to develop an engaging and interesting PowerPoint presentation to accom= pany their speech. Delegates are asked to bring along a brief =5Bno more th= an 10 minutes=5D presentation which has been recently used. Each delegate w= ill be given an opportunity to present this to the group, whereupon feedbac= k will be given and practical ways in which to improve. This may take the f= orm of help with your slides, your presentation technique, or simply ideas = to help you create a slicker, more effective presentation.&=23xa0;
<= b>Writing Press Releases - London, 19th November
T= his is an ideal training course for those who want to use press releases as= a technique for publicising an event or calling attention to an issue. Thr= oughout the workshop delegates will develop the skills to produce a well-wr= itten, well-distributed and well-timed press release, and to appreciate tha= t it is not difficult or expensive to produce, yet can be effective and use= ful. The key to writing an effective press release is getting it read and t= he information published. With these objectives in mind, this module is des= igned to equip delegates with the most important elements of the press rele= ase, which are a clear and engaging text, careful selection of recipients, = and good timing of release.
<= b>Effective Training Skills - train the trainer - Geneva, 1st December<= /div>
T= his workshop is ideal for those who are required to effectively train emplo= yees, colleagues or clients in an interesting, engaging and confident manne= r, in a way that is practical and which will help delegates to gain new ski= lls, knowledge and understanding.
<= b>Crisis Communication & Media Management Strategies - Geneva, 1st = December
T= his workshop combines advanced media skills with crisis communication tacti= cs and is aimed at those at the highest level within the organisation who w= ill already have significant experience in dealing with the media. By the e= nd of the workshop the following areas will be covered, through practical a= ctivities and individual endeavour: - a better awareness of media communica= tion problems and good practice; familiarity with the latest organisational= communication systems; demonstrating good practice in handling real proble= ms with media; how to develop media strategies for prevention; how to manag= e high profile media events and crises and how to handle bad news/adverse p= ublicity.
<= b>Media Strategies & Campaigns - Geneva, 2nd December
T= his workshop is aimed at individuals and organisations who want to get the = media working for them and with them.&=23xa0; Working with the media is an = effective way to influence attitudes and opinions about your programme, iss= ue or product. In this workshop we aim to help you develop and manage a med= ia relations campaign, which is one of the most effective ways to reach you= r target audience. This workshop is ideal if you or your colleagues have a = campaign to run or a new product to launch and you would like to harness th= e media to full effect.
<= b>Team Building & Group Dynamics - Geneva, 2nd December
T= his workshop is aimed at those of who are responsible for a group of people= and you want some practical tips on how to deal with conflict resolution, = anger management, team building and relationships within the group. If you = need the skills to get your group working better together, then this worksh= op is an excellent way to start the ball rolling.
<= b>Presentation & Communication Skills - Geneva, 4th December
=
I= ndividuals and organisations who want to improve the way they present and c= ommunicate - both formally and informally - for effectiveness and profitabi= lity.&=23xa0; Through the use of group work and individual activities, this= workshop provides every participant with an opportunity to practice the te= chniques and skills needed to prepare and deliver a great presentation, and= introduces the wide number of sources of noise or interference that can en= ter into the communication process.
K= ind regards,
S= ales & Marketing Team, www.crosshand= straining.org.uk
c= rosshands ltd, coreley, shropshire sy8 3ar, t: 01584 890970; incorporated i= n england & wales. company registration: 3136393 VAT registration: 682 = 1126 51
Y= ou have been sent this mail because we understand that you wish to receive = information about our training services, however, if this is incorrect, or = you no longer wish to receive mail, please email remove=40crosshandstraining.org.uk and = your details will be removed immediately.
&= =23xa0;
&= =23xa0;
&= =23xa0;
&= =23xa0;
= --Direct-Mail-MIME-Boundary-2-- From BATV+2c9f98a1cc69030df3d7+2272+infradead.org+hch@bombadil.srs.infradead.org Thu Nov 12 04:03:58 2009 X-Spam-Checker-Version: SpamAssassin 3.3.0-rupdated (updated) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_61,J_CHICKENPOX_63,J_CHICKENPOX_64,J_CHICKENPOX_65, J_CHICKENPOX_66,J_CHICKENPOX_71 autolearn=no version=3.3.0-rupdated Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id nACA3puE240951 for ; Thu, 12 Nov 2009 04:03:58 -0600 X-ASG-Debug-ID: 1258020250-219a01090000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 73AFC1D932A7; Thu, 12 Nov 2009 02:04:10 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Ahce1pw7EvFe2Gyz; Thu, 12 Nov 2009 02:04:10 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.69 #1 (Red Hat Linux)) id 1N8WXA-0006gJ-58; Thu, 12 Nov 2009 10:04:08 +0000 Date: Thu, 12 Nov 2009 05:04:08 -0500 From: Christoph Hellwig To: Alex Elder Cc: Barry Naujok , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 06/14] repair: use a btree instead of a radix tree for theprefetch queue Subject: Re: [PATCH 06/14] repair: use a btree instead of a radix tree for theprefetch queue Message-ID: <20091112100408.GA25058@infradead.org> References: <20090902175840.740632507@bombadil.infradead.org> <1AB9A794DBDDF54A8A81BE2296F7BDFE83ADEB@cf--amer001e--3.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE83ADEB@cf--amer001e--3.americas.sgi.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1258020250 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Oct 21, 2009 at 12:12:33PM -0500, Alex Elder wrote: > - Is this code worthy of putting into a library, so other > XFS user space can use it? We can do this if we need it - git even tracks history over renames. > - Is the radix tree code worth putting into a library and > saving, for similar reasons (I didn't look at that code). I don't think we hould keep dead core around. We can resurrect it from git history if needed (don't think we'll need it though). > - I accept that this uses less memory for sparsely populated > key space than radix trees; but it would be nice if that > could be characterized a bit more precisely (i.e., what > will the range of values that'll be represented be, just > how sparse is it, and at what point does this really > pay off?). > - Related to the previous one--it would be good to have > a little info about why the value 7 was chosen as the > number of keys per node. Perhaps I just don't know > enough of the history (or content of the upcoming > patches). Maybe Barry still remembers some of this. I've added his current personal address to the Cc list. > - A number of external interfaces defined are not used > in the (current) xfs_repair code. (That's OK, but > they could be removed if they're never expected to > to be used--e.g. btree_peek_prev(), and btree_peek_next()). True. Although having the commited first and then removed would at least assure we have it in the git history so we can easily find it again. > > +#include > > +#include "btree.h" > > + > > + > > Note that the value of BTREE_KEY_MAX *must* be greater than 2, or > this code will not work. Maybe nobody should be trying to use 2 > here anyway, but I would like to see a comment, e.g., /* Must be 3 or more */ Thanks, I've added a comment to the updated version of the patch. > > pthread_mutex_lock(&args->lock); > > - while (!args->queuing_done || args->primary_io_queue.height) { > > There is a btree_is_empty(btree_root) function, you might > as well use it here (it is clearer what you're doing anyway). Indeed, changed. > > - ASSERT(args->primary_io_queue.height == 0); > > - ASSERT(args->secondary_io_queue.height == 0); > > btree_is_empty() would be better here also. > > > + ASSERT(btree_find(args->primary_io_queue, 0, NULL) == NULL); > > + ASSERT(btree_find(args->secondary_io_queue, 0, NULL) == NULL); Fixed up as well. Current version of the patch below: -- Subject: repair: use a btree instead of a radix tree for the prefetch queue From: Barry Naujok Currently the prefetch queue in xfs_repair uses a radix tree implementation derived from the Linux kernel one to manage it's prefetch queue. The radix tree implement is not very memory efficient for sparse indices, so replace it with a btree implementation that is much more efficient. This is not that important for the prefetch queue but will be very important for the next memory optimization patches which need a tree to store things like the block map which are very sparse, and we do not want to deal with two tree implementations (or rather three given that we still have avl.c around) Signed-off-by: Barry Naujok Signed-off-by: Christoph Hellwig Reviewed-by: Alex Elder Index: xfsprogs-dev/repair/Makefile =================================================================== --- xfsprogs-dev.orig/repair/Makefile 2009-11-12 10:49:49.029254650 +0100 +++ xfsprogs-dev/repair/Makefile 2009-11-12 10:53:01.087004222 +0100 @@ -9,15 +9,15 @@ LSRCFILES = README LTCOMMAND = xfs_repair -HFILES = agheader.h attr_repair.h avl.h avl64.h bmap.h dinode.h dir.h \ - dir2.h err_protos.h globals.h incore.h protos.h rt.h \ - progress.h scan.h versions.h prefetch.h radix-tree.h threads.h +HFILES = agheader.h attr_repair.h avl.h avl64.h bmap.h btree.h \ + dinode.h dir.h dir2.h err_protos.h globals.h incore.h protos.h rt.h \ + progress.h scan.h versions.h prefetch.h threads.h -CFILES = agheader.c attr_repair.c avl.c avl64.c bmap.c dino_chunks.c \ - dinode.c dir.c dir2.c globals.c incore.c \ +CFILES = agheader.c attr_repair.c avl.c avl64.c bmap.c btree.c \ + dino_chunks.c dinode.c dir.c dir2.c globals.c incore.c \ incore_bmc.c init.c incore_ext.c incore_ino.c phase1.c \ phase2.c phase3.c phase4.c phase5.c phase6.c phase7.c \ - progress.c prefetch.c radix-tree.c rt.c sb.c scan.c threads.c \ + progress.c prefetch.c rt.c sb.c scan.c threads.c \ versions.c xfs_repair.c LLDLIBS = $(LIBXFS) $(LIBXLOG) $(LIBUUID) $(LIBRT) $(LIBPTHREAD) Index: xfsprogs-dev/repair/btree.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfsprogs-dev/repair/btree.c 2009-11-12 10:54:07.733011893 +0100 @@ -0,0 +1,1238 @@ +/* + * Copyright (c) 2007, Silicon Graphics, Inc. Barry Naujok + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "btree.h" + +/* + * Maximum number of keys per node. Must be greater than 2 for the code + * to work. + */ +#define BTREE_KEY_MAX 7 +#define BTREE_KEY_MIN (BTREE_KEY_MAX / 2) + +#define BTREE_PTR_MAX (BTREE_KEY_MAX + 1) + +struct btree_node { + unsigned long num_keys; + unsigned long keys[BTREE_KEY_MAX]; + struct btree_node *ptrs[BTREE_PTR_MAX]; +}; + +struct btree_cursor { + struct btree_node *node; + int index; +}; + +struct btree_root { + struct btree_node *root_node; + struct btree_cursor *cursor; /* track path to end leaf */ + int height; + /* lookup cache */ + int keys_valid; /* set if the cache is valid */ + unsigned long cur_key; + unsigned long next_key; + void *next_value; + unsigned long prev_key; + void *prev_value; +#ifdef BTREE_STATS + struct btree_stats { + unsigned long num_items; + unsigned long max_items; + int alloced; + int cache_hits; + int cache_misses; + int lookup; + int find; + int key_update; + int value_update; + int insert; + int delete; + int inc_height; + int dec_height; + int shift_prev; + int shift_next; + int split; + int merge_prev; + int merge_next; + int balance_prev; + int balance_next; + } stats; +#endif +}; + + +static struct btree_node * +btree_node_alloc(void) +{ + return calloc(1, sizeof(struct btree_node)); +} + +static void +btree_node_free( + struct btree_node *node) +{ + free(node); +} + +static void +btree_free_nodes( + struct btree_node *node, + int level) +{ + int i; + + if (level) + for (i = 0; i <= node->num_keys; i++) + btree_free_nodes(node->ptrs[i], level - 1); + btree_node_free(node); +} + +static void +__btree_init( + struct btree_root *root) +{ + memset(root, 0, sizeof(struct btree_root)); + root->height = 1; + root->cursor = calloc(1, sizeof(struct btree_cursor)); + root->root_node = btree_node_alloc(); + ASSERT(root->root_node); +#ifdef BTREE_STATS + root->stats.max_items = 1; + root->stats.alloced += 1; +#endif +} + +static void +__btree_free( + struct btree_root *root) +{ + btree_free_nodes(root->root_node, root->height - 1); + free(root->cursor); + root->height = 0; + root->cursor = NULL; + root->root_node = NULL; +} + +void +btree_init( + struct btree_root **root) +{ + *root = calloc(1, sizeof(struct btree_root)); + __btree_init(*root); +} + +void +btree_clear( + struct btree_root *root) +{ + __btree_free(root); + __btree_init(root); +} + +void +btree_destroy( + struct btree_root *root) +{ + __btree_free(root); + free(root); +} + +int +btree_is_empty( + struct btree_root *root) +{ + return root->root_node->num_keys == 0; +} + +static inline void +btree_invalidate_cursor( + struct btree_root *root) +{ + root->cursor[0].node = NULL; + root->keys_valid = 0; +} + +static inline unsigned long +btree_key_of_cursor( + struct btree_cursor *cursor, + int height) +{ + while (cursor->node->num_keys == cursor->index && --height > 0) + cursor++; + return cursor->node->keys[cursor->index]; +} + +static void * +btree_get_prev( + struct btree_root *root, + unsigned long *key) +{ + struct btree_cursor *cur = root->cursor; + int level = 0; + struct btree_node *node; + + if (cur->index > 0) { + if (key) + *key = cur->node->keys[cur->index - 1]; + return cur->node->ptrs[cur->index - 1]; + } + + /* else need to go up and back down the tree to find the previous */ + + while (cur->index == 0) { + if (++level == root->height) + return NULL; + cur++; + } + + /* the key is in the current level */ + if (key) + *key = cur->node->keys[cur->index - 1]; + + /* descend back down the right side to get the pointer */ + node = cur->node->ptrs[cur->index - 1]; + while (level--) + node = node->ptrs[node->num_keys]; + return node; +} + +static void * +btree_get_next( + struct btree_root *root, + unsigned long *key) +{ + struct btree_cursor *cur = root->cursor; + int level = 0; + struct btree_node *node; + + while (cur->index == cur->node->num_keys) { + if (++level == root->height) + return NULL; + cur++; + } + if (level == 0) { + if (key) { + cur->index++; + *key = btree_key_of_cursor(cur, root->height); + cur->index--; + } + return cur->node->ptrs[cur->index + 1]; + } + + node = cur->node->ptrs[cur->index + 1]; + while (--level > 0) + node = node->ptrs[0]; + if (key) + *key = node->keys[0]; + return node->ptrs[0]; +} + +/* + * Lookup/Search functions + */ + +static int +btree_do_search( + struct btree_root *root, + unsigned long key) +{ + unsigned long k = 0; + struct btree_cursor *cur = root->cursor + root->height; + struct btree_node *node = root->root_node; + int height = root->height; + int key_found = 0; + int i; + + while (--height >= 0) { + cur--; + for (i = 0; i < node->num_keys; i++) + if (node->keys[i] >= key) { + k = node->keys[i]; + key_found = 1; + break; + } + cur->node = node; + cur->index = i; + node = node->ptrs[i]; + } + root->keys_valid = key_found; + if (!key_found) + return 0; + + root->cur_key = k; + root->next_value = NULL; /* do on-demand next value lookup */ + root->prev_value = btree_get_prev(root, &root->prev_key); + return 1; +} + +static int +btree_search( + struct btree_root *root, + unsigned long key) +{ + if (root->keys_valid && key <= root->cur_key && + (!root->prev_value || key > root->prev_key)) { +#ifdef BTREE_STATS + root->stats.cache_hits++; +#endif + return 1; + } +#ifdef BTREE_STATS + root->stats.cache_misses++; +#endif + return btree_do_search(root, key); +} + +void * +btree_find( + struct btree_root *root, + unsigned long key, + unsigned long *actual_key) +{ +#ifdef BTREE_STATS + root->stats.find += 1; +#endif + if (!btree_search(root, key)) + return NULL; + + if (actual_key) + *actual_key = root->cur_key; + return root->cursor->node->ptrs[root->cursor->index]; +} + +void * +btree_lookup( + struct btree_root *root, + unsigned long key) +{ +#ifdef BTREE_STATS + root->stats.lookup += 1; +#endif + if (!btree_search(root, key) || root->cur_key != key) + return NULL; + return root->cursor->node->ptrs[root->cursor->index]; +} + +void * +btree_peek_prev( + struct btree_root *root, + unsigned long *key) +{ + if (!root->keys_valid) + return NULL; + if (key) + *key = root->prev_key; + return root->prev_value; +} + +void * +btree_peek_next( + struct btree_root *root, + unsigned long *key) +{ + if (!root->keys_valid) + return NULL; + if (!root->next_value) + root->next_value = btree_get_next(root, &root->next_key); + if (key) + *key = root->next_key; + return root->next_value; +} + +static void * +btree_move_cursor_to_next( + struct btree_root *root, + unsigned long *key) +{ + struct btree_cursor *cur = root->cursor; + int level = 0; + + while (cur->index == cur->node->num_keys) { + if (++level == root->height) + return NULL; + cur++; + } + cur->index++; + if (level == 0) { + if (key) + *key = btree_key_of_cursor(cur, root->height); + return cur->node->ptrs[cur->index]; + } + + while (--level >= 0) { + root->cursor[level].node = cur->node->ptrs[cur->index]; + root->cursor[level].index = 0; + cur--; + } + if (key) + *key = cur->node->keys[0]; + return cur->node->ptrs[0]; +} + +void * +btree_lookup_next( + struct btree_root *root, + unsigned long *key) +{ + void *value; + + if (!root->keys_valid) + return NULL; + + root->prev_key = root->cur_key; + root->prev_value = root->cursor->node->ptrs[root->cursor->index]; + + value = btree_move_cursor_to_next(root, &root->cur_key); + if (!value) { + btree_invalidate_cursor(root); + return NULL; + } + root->next_value = NULL; /* on-demand next value fetch */ + if (key) + *key = root->cur_key; + return value; +} + +static void * +btree_move_cursor_to_prev( + struct btree_root *root, + unsigned long *key) +{ + struct btree_cursor *cur = root->cursor; + int level = 0; + + while (cur->index == 0) { + if (++level == root->height) + return NULL; + cur++; + } + cur->index--; + if (key) /* the key is in the current level */ + *key = cur->node->keys[cur->index]; + while (level > 0) { + level--; + root->cursor[level].node = cur->node->ptrs[cur->index]; + root->cursor[level].index = root->cursor[level].node->num_keys; + cur--; + } + return cur->node->ptrs[cur->index]; +} + +void * +btree_lookup_prev( + struct btree_root *root, + unsigned long *key) +{ + void *value; + + if (!root->keys_valid) + return NULL; + + value = btree_move_cursor_to_prev(root, &root->cur_key); + if (!value) + return NULL; + root->prev_value = btree_get_prev(root, &root->prev_key); + root->next_value = NULL; /* on-demand next value fetch */ + if (key) + *key = root->cur_key; + return value; +} + +void * +btree_uncached_lookup( + struct btree_root *root, + unsigned long key) +{ + /* cursor-less (ie. uncached) lookup */ + int height = root->height - 1; + struct btree_node *node = root->root_node; + int i; + int key_found = 0; + + while (height >= 0) { + for (i = 0; i < node->num_keys; i++) + if (node->keys[i] >= key) { + key_found = node->keys[i] == key; + break; + } + node = node->ptrs[i]; + height--; + } + return key_found ? node : NULL; +} + +/* Update functions */ + +static inline void +btree_update_node_key( + struct btree_root *root, + struct btree_cursor *cursor, + int level, + unsigned long new_key) +{ + int i; + +#ifdef BTREE_STATS + root->stats.key_update += 1; +#endif + + cursor += level; + for (i = level; i < root->height; i++) { + if (cursor->index < cursor->node->num_keys) { + cursor->node->keys[cursor->index] = new_key; + break; + } + cursor++; + } +} + +int +btree_update_key( + struct btree_root *root, + unsigned long old_key, + unsigned long new_key) +{ + if (!btree_search(root, old_key) || root->cur_key != old_key) + return ENOENT; + + if (root->next_value && new_key >= root->next_key) + return EINVAL; + + if (root->prev_value && new_key <= root->prev_key) + return EINVAL; + + btree_update_node_key(root, root->cursor, 0, new_key); + + return 0; +} + +int +btree_update_value( + struct btree_root *root, + unsigned long key, + void *new_value) +{ + if (!new_value) + return EINVAL; + + if (!btree_search(root, key) || root->cur_key != key) + return ENOENT; + +#ifdef BTREE_STATS + root->stats.value_update += 1; +#endif + root->cursor->node->ptrs[root->cursor->index] = new_value; + + return 0; +} + +/* + * Cursor modification functions - used for inserting and deleting + */ + +static struct btree_cursor * +btree_copy_cursor_prev( + struct btree_root *root, + struct btree_cursor *dest_cursor, + int level) +{ + struct btree_cursor *src_cur = root->cursor + level; + struct btree_cursor *dst_cur; + int l = level; + int i; + + if (level >= root->height) + return NULL; + + while (src_cur->index == 0) { + if (++l >= root->height) + return NULL; + src_cur++; + } + for (i = l; i < root->height; i++) + dest_cursor[i] = *src_cur++; + + dst_cur = dest_cursor + l; + dst_cur->index--; + while (l-- >= level) { + dest_cursor[l].node = dst_cur->node->ptrs[dst_cur->index]; + dest_cursor[l].index = dest_cursor[l].node->num_keys; + dst_cur--; + } + return dest_cursor; +} + +static struct btree_cursor * +btree_copy_cursor_next( + struct btree_root *root, + struct btree_cursor *dest_cursor, + int level) +{ + struct btree_cursor *src_cur = root->cursor + level; + struct btree_cursor *dst_cur; + int l = level; + int i; + + if (level >= root->height) + return NULL; + + while (src_cur->index == src_cur->node->num_keys) { + if (++l >= root->height) + return NULL; + src_cur++; + } + for (i = l; i < root->height; i++) + dest_cursor[i] = *src_cur++; + + dst_cur = dest_cursor + l; + dst_cur->index++; + while (l-- >= level) { + dest_cursor[l].node = dst_cur->node->ptrs[dst_cur->index]; + dest_cursor[l].index = 0; + dst_cur--; + } + return dest_cursor; +} + +/* + * Shift functions + * + * Tries to move items in the current leaf to its sibling if it has space. + * Used in both insert and delete functions. + * Returns the number of items shifted. + */ + +static int +btree_shift_to_prev( + struct btree_root *root, + int level, + struct btree_cursor *prev_cursor, + int num_children) +{ + struct btree_node *node; + struct btree_node *prev_node; + int num_remain; /* # of keys left in "node" */ + unsigned long key; + int i; + + if (!prev_cursor || !num_children) + return 0; + + prev_node = prev_cursor[level].node; + node = root->cursor[level].node; + + ASSERT(num_children > 0 && num_children <= node->num_keys + 1); + + if ((prev_node->num_keys + num_children) > BTREE_KEY_MAX) + return 0; + +#ifdef BTREE_STATS + root->stats.shift_prev += 1; +#endif + + num_remain = node->num_keys - num_children; + ASSERT(num_remain == -1 || num_remain >= BTREE_KEY_MIN); + + /* shift parent keys around */ + level++; + if (num_remain > 0) + key = node->keys[num_children - 1]; + else + key = btree_key_of_cursor(root->cursor + level, + root->height - level); + while (prev_cursor[level].index == prev_cursor[level].node->num_keys) { + level++; + ASSERT(level < root->height); + } + prev_node->keys[prev_node->num_keys] = + prev_cursor[level].node->keys[prev_cursor[level].index]; + prev_cursor[level].node->keys[prev_cursor[level].index] = key; + + /* copy pointers and keys to the end of the prev node */ + for (i = 0; i < num_children - 1; i++) { + prev_node->keys[prev_node->num_keys + 1 + i] = node->keys[i]; + prev_node->ptrs[prev_node->num_keys + 1 + i] = node->ptrs[i]; + } + prev_node->ptrs[prev_node->num_keys + 1 + i] = node->ptrs[i]; + prev_node->num_keys += num_children; + + /* move remaining pointers/keys to start of node */ + if (num_remain >= 0) { + for (i = 0; i < num_remain; i++) { + node->keys[i] = node->keys[num_children + i]; + node->ptrs[i] = node->ptrs[num_children + i]; + } + node->ptrs[i] = node->ptrs[num_children + i]; + node->num_keys = num_remain; + } else + node->num_keys = 0; + + return num_children; +} + +static int +btree_shift_to_next( + struct btree_root *root, + int level, + struct btree_cursor *next_cursor, + int num_children) +{ + struct btree_node *node; + struct btree_node *next_node; + int num_remain; /* # of children left in node */ + int i; + + if (!next_cursor || !num_children) + return 0; + + node = root->cursor[level].node; + next_node = next_cursor[level].node; + + ASSERT(num_children > 0 && num_children <= node->num_keys + 1); + + if ((next_node->num_keys + num_children) > BTREE_KEY_MAX) + return 0; + + num_remain = node->num_keys + 1 - num_children; + ASSERT(num_remain == 0 || num_remain > BTREE_KEY_MIN); + +#ifdef BTREE_STATS + root->stats.shift_next += 1; +#endif + + /* make space for "num_children" items at beginning of next-leaf */ + i = next_node->num_keys; + next_node->ptrs[num_children + i] = next_node->ptrs[i]; + while (--i >= 0) { + next_node->keys[num_children + i] = next_node->keys[i]; + next_node->ptrs[num_children + i] = next_node->ptrs[i]; + } + + /* update keys in parent and next node from parent */ + do { + level++; + ASSERT(level < root->height); + } while (root->cursor[level].index == + root->cursor[level].node->num_keys); + + next_node->keys[num_children - 1] = + root->cursor[level].node->keys[root->cursor[level].index]; + root->cursor[level].node->keys[root->cursor[level].index] = + node->keys[node->num_keys - num_children]; + + /* copy last "num_children" items from node into start of next-node */ + for (i = 0; i < num_children - 1; i++) { + next_node->keys[i] = node->keys[num_remain + i]; + next_node->ptrs[i] = node->ptrs[num_remain + i]; + } + next_node->ptrs[i] = node->ptrs[num_remain + i]; + next_node->num_keys += num_children; + + if (num_remain > 0) + node->num_keys -= num_children; + else + node->num_keys = 0; + + return num_children; +} + +/* + * Insertion functions + */ + +static struct btree_node * +btree_increase_height( + struct btree_root *root) +{ + struct btree_node *new_root; + struct btree_cursor *new_cursor; + + new_cursor = realloc(root->cursor, (root->height + 1) * + sizeof(struct btree_cursor)); + if (!new_cursor) + return NULL; + root->cursor = new_cursor; + + new_root = btree_node_alloc(); + if (!new_root) + return NULL; + +#ifdef BTREE_STATS + root->stats.alloced += 1; + root->stats.inc_height += 1; + root->stats.max_items *= BTREE_PTR_MAX; +#endif + + new_root->ptrs[0] = root->root_node; + root->root_node = new_root; + + root->cursor[root->height].node = new_root; + root->cursor[root->height].index = 0; + + root->height++; + + return new_root; +} + +static int +btree_insert_item( + struct btree_root *root, + int level, + unsigned long key, + void *value); + + +static struct btree_node * +btree_split( + struct btree_root *root, + int level, + unsigned long key, + int *index) +{ + struct btree_node *node = root->cursor[level].node; + struct btree_node *new_node; + int i; + + new_node = btree_node_alloc(); + if (!new_node) + return NULL; + + if (btree_insert_item(root, level + 1, node->keys[BTREE_KEY_MIN], + new_node) != 0) { + btree_node_free(new_node); + return NULL; + } + +#ifdef BTREE_STATS + root->stats.alloced += 1; + root->stats.split += 1; +#endif + + for (i = 0; i < BTREE_KEY_MAX - BTREE_KEY_MIN - 1; i++) { + new_node->keys[i] = node->keys[BTREE_KEY_MIN + 1 + i]; + new_node->ptrs[i] = node->ptrs[BTREE_KEY_MIN + 1 + i]; + } + new_node->ptrs[i] = node->ptrs[BTREE_KEY_MIN + 1 + i]; + new_node->num_keys = BTREE_KEY_MAX - BTREE_KEY_MIN - 1; + + node->num_keys = BTREE_KEY_MIN; + if (key < node->keys[BTREE_KEY_MIN]) + return node; /* index doesn't change */ + + /* insertion point is in new node... */ + *index -= BTREE_KEY_MIN + 1; + return new_node; +} + +static int +btree_insert_shift_to_prev( + struct btree_root *root, + int level, + int *index) +{ + struct btree_cursor tmp_cursor[root->height]; + int n; + + if (*index <= 0) + return -1; + + if (!btree_copy_cursor_prev(root, tmp_cursor, level + 1)) + return -1; + + n = MIN(*index, (BTREE_PTR_MAX - tmp_cursor[level].node->num_keys) / 2); + if (!n || !btree_shift_to_prev(root, level, tmp_cursor, n)) + return -1; + + *index -= n; + return 0; +} + +static int +btree_insert_shift_to_next( + struct btree_root *root, + int level, + int *index) +{ + struct btree_cursor tmp_cursor[root->height]; + int n; + + if (*index >= BTREE_KEY_MAX) + return -1; + + if (!btree_copy_cursor_next(root, tmp_cursor, level + 1)) + return -1; + + n = MIN(BTREE_KEY_MAX - *index, + (BTREE_PTR_MAX - tmp_cursor[level].node->num_keys) / 2); + if (!n || !btree_shift_to_next(root, level, tmp_cursor, n)) + return -1; + return 0; +} + +static int +btree_insert_item( + struct btree_root *root, + int level, + unsigned long key, + void *value) +{ + struct btree_node *node = root->cursor[level].node; + int index = root->cursor[level].index; + int i; + + if (node->num_keys == BTREE_KEY_MAX) { + if (btree_insert_shift_to_prev(root, level, &index) == 0) + goto insert; + if (btree_insert_shift_to_next(root, level, &index) == 0) + goto insert; + if (level == root->height - 1) { + if (!btree_increase_height(root)) + return ENOMEM; + } + node = btree_split(root, level, key, &index); + if (!node) + return ENOMEM; + } +insert: + ASSERT(index <= node->num_keys); + + i = node->num_keys; + node->ptrs[i + 1] = node->ptrs[i]; + while (--i >= index) { + node->keys[i + 1] = node->keys[i]; + node->ptrs[i + 1] = node->ptrs[i]; + } + + node->num_keys++; + node->keys[index] = key; + + if (level == 0) + node->ptrs[index] = value; + else + node->ptrs[index + 1] = value; + + return 0; +} + + + +int +btree_insert( + struct btree_root *root, + unsigned long key, + void *value) +{ + int result; + + if (!value) + return EINVAL; + + if (btree_search(root, key) && root->cur_key == key) + return EEXIST; + +#ifdef BTREE_STATS + root->stats.insert += 1; + root->stats.num_items += 1; +#endif + + result = btree_insert_item(root, 0, key, value); + + btree_invalidate_cursor(root); + + return result; +} + + +/* + * Deletion functions + * + * Rather more complicated as deletions has 4 ways to go once a node + * ends up with less than the minimum number of keys: + * - move remainder to previous node + * - move remainder to next node + * (both will involve a parent deletion which may recurse) + * - balance by moving some items from previous node + * - balance by moving some items from next node + */ + +static void +btree_decrease_height( + struct btree_root *root) +{ + struct btree_node *old_root = root->root_node; + + ASSERT(old_root->num_keys == 0); + +#ifdef BTREE_STATS + root->stats.alloced -= 1; + root->stats.dec_height += 1; + root->stats.max_items /= BTREE_PTR_MAX; +#endif + root->root_node = old_root->ptrs[0]; + btree_node_free(old_root); + root->height--; +} + +static int +btree_merge_with_prev( + struct btree_root *root, + int level, + struct btree_cursor *prev_cursor) +{ + if (!prev_cursor) + return 0; + + if (!btree_shift_to_prev(root, level, prev_cursor, + root->cursor[level].node->num_keys + 1)) + return 0; + +#ifdef BTREE_STATS + root->stats.merge_prev += 1; +#endif + return 1; +} + +static int +btree_merge_with_next( + struct btree_root *root, + int level, + struct btree_cursor *next_cursor) +{ + if (!next_cursor) + return 0; + + if (!btree_shift_to_next(root, level, next_cursor, + root->cursor[level].node->num_keys + 1)) + return 0; + +#ifdef BTREE_STATS + root->stats.merge_next += 1; +#endif + return 1; +} + +static int +btree_balance_with_prev( + struct btree_root *root, + int level, + struct btree_cursor *prev_cursor) +{ + struct btree_cursor *root_cursor = root->cursor; + + if (!prev_cursor) + return 0; + ASSERT(prev_cursor[level].node->num_keys > BTREE_KEY_MIN); + +#ifdef BTREE_STATS + root->stats.balance_prev += 1; +#endif + /* + * Move some nodes from the prev node into the current node. + * As the shift operation is a right shift and is relative to + * the root cursor, make the root cursor the prev cursor and + * pass in the root cursor as the next cursor. + */ + + root->cursor = prev_cursor; + if (!btree_shift_to_next(root, level, root_cursor, + (prev_cursor[level].node->num_keys + 1 - BTREE_KEY_MIN) / 2)) + abort(); + root->cursor = root_cursor; + + return 1; +} + +static int +btree_balance_with_next( + struct btree_root *root, + int level, + struct btree_cursor *next_cursor) +{ + struct btree_cursor *root_cursor = root->cursor; + + if (!next_cursor) + return 0; + assert(next_cursor[level].node->num_keys > BTREE_KEY_MIN); + +#ifdef btree_stats + root->stats.balance_next += 1; +#endif + /* + * move some nodes from the next node into the current node. + * as the shift operation is a left shift and is relative to + * the root cursor, make the root cursor the next cursor and + * pass in the root cursor as the prev cursor. + */ + + root->cursor = next_cursor; + if (!btree_shift_to_prev(root, level, root_cursor, + (next_cursor[level].node->num_keys + 1 - BTREE_KEY_MIN) / 2)) + abort(); + root->cursor = root_cursor; + + return 1; + +} + +static void +btree_delete_key( + struct btree_root *root, + int level); + +/* + * btree_delete_node: + * + * Return 0 if it's done or 1 if the next level needs to be collapsed + */ +static void +btree_delete_node( + struct btree_root *root, + int level) +{ + struct btree_cursor prev_cursor[root->height]; + struct btree_cursor next_cursor[root->height]; + struct btree_cursor *pc; + struct btree_cursor *nc; + + /* + * the node has underflowed, grab or merge keys/items from a + * neighbouring node. + */ + + if (level == root->height - 1) { + if (level > 0 && root->root_node->num_keys == 0) + btree_decrease_height(root); + return; + } + + pc = btree_copy_cursor_prev(root, prev_cursor, level + 1); + if (!btree_merge_with_prev(root, level, pc)) { + nc = btree_copy_cursor_next(root, next_cursor, level + 1); + if (!btree_merge_with_next(root, level, nc)) { + /* merging failed, try redistrubution */ + if (!btree_balance_with_prev(root, level, pc) && + !btree_balance_with_next(root, level, nc)) + abort(); + return; /* when balancing, then the node isn't freed */ + } + } + +#ifdef BTREE_STATS + root->stats.alloced -= 1; +#endif + btree_node_free(root->cursor[level].node); + + btree_delete_key(root, level + 1); +} + +static void +btree_delete_key( + struct btree_root *root, + int level) +{ + struct btree_node *node = root->cursor[level].node; + int index = root->cursor[level].index; + + node->num_keys--; + if (index <= node->num_keys) { + /* + * if not deleting the last item, shift higher items down + * to cover the item being deleted + */ + while (index < node->num_keys) { + node->keys[index] = node->keys[index + 1]; + node->ptrs[index] = node->ptrs[index + 1]; + index++; + } + node->ptrs[index] = node->ptrs[index + 1]; + } else { + /* + * else update the associated parent key as the last key + * in the leaf has changed + */ + btree_update_node_key(root, root->cursor, level + 1, + node->keys[node->num_keys]); + } + /* + * if node underflows, either merge with sibling or rebalance + * with sibling. + */ + if (node->num_keys < BTREE_KEY_MIN) + btree_delete_node(root, level); +} + +void * +btree_delete( + struct btree_root *root, + unsigned long key) +{ + void *value; + + value = btree_lookup(root, key); + if (!value) + return NULL; + +#ifdef BTREE_STATS + root->stats.delete += 1; + root->stats.num_items -= 1; +#endif + + btree_delete_key(root, 0); + + btree_invalidate_cursor(root); + + return value; +} + +#ifdef BTREE_STATS +void +btree_print_stats( + struct btree_root *root, + FILE *f) +{ + unsigned long max_items = root->stats.max_items * + (root->root_node->num_keys + 1); + + fprintf(f, "\tnum_items = %lu, max_items = %lu (%lu%%)\n", + root->stats.num_items, max_items, + root->stats.num_items * 100 / max_items); + fprintf(f, "\talloced = %d nodes, %lu bytes, %lu bytes per item\n", + root->stats.alloced, + root->stats.alloced * sizeof(struct btree_node), + root->stats.alloced * sizeof(struct btree_node) / + root->stats.num_items); + fprintf(f, "\tlookup = %d\n", root->stats.lookup); + fprintf(f, "\tfind = %d\n", root->stats.find); + fprintf(f, "\tcache_hits = %d\n", root->stats.cache_hits); + fprintf(f, "\tcache_misses = %d\n", root->stats.cache_misses); + fprintf(f, "\tkey_update = %d\n", root->stats.key_update); + fprintf(f, "\tvalue_update = %d\n", root->stats.value_update); + fprintf(f, "\tinsert = %d\n", root->stats.insert); + fprintf(f, "\tshift_prev = %d\n", root->stats.shift_prev); + fprintf(f, "\tshift_next = %d\n", root->stats.shift_next); + fprintf(f, "\tsplit = %d\n", root->stats.split); + fprintf(f, "\tinc_height = %d\n", root->stats.inc_height); + fprintf(f, "\tdelete = %d\n", root->stats.delete); + fprintf(f, "\tmerge_prev = %d\n", root->stats.merge_prev); + fprintf(f, "\tmerge_next = %d\n", root->stats.merge_next); + fprintf(f, "\tbalance_prev = %d\n", root->stats.balance_prev); + fprintf(f, "\tbalance_next = %d\n", root->stats.balance_next); + fprintf(f, "\tdec_height = %d\n", root->stats.dec_height); +} +#endif Index: xfsprogs-dev/repair/btree.h =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfsprogs-dev/repair/btree.h 2009-11-12 10:53:01.091025964 +0100 @@ -0,0 +1,102 @@ +/* + * Copyright (c) 2007 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef _BTREE_H +#define _BTREE_H + + +struct btree_root; + +void +btree_init( + struct btree_root **root); + +void +btree_destroy( + struct btree_root *root); + +int +btree_is_empty( + struct btree_root *root); + +void * +btree_lookup( + struct btree_root *root, + unsigned long key); + +void * +btree_find( + struct btree_root *root, + unsigned long key, + unsigned long *actual_key); + +void * +btree_peek_prev( + struct btree_root *root, + unsigned long *key); + +void * +btree_peek_next( + struct btree_root *root, + unsigned long *key); + +void * +btree_lookup_next( + struct btree_root *root, + unsigned long *key); + +void * +btree_lookup_prev( + struct btree_root *root, + unsigned long *key); + +int +btree_insert( + struct btree_root *root, + unsigned long key, + void *value); + +void * +btree_delete( + struct btree_root *root, + unsigned long key); + +int +btree_update_key( + struct btree_root *root, + unsigned long old_key, + unsigned long new_key); + +int +btree_update_value( + struct btree_root *root, + unsigned long key, + void *new_value); + +void +btree_clear( + struct btree_root *root); + +#ifdef BTREE_STATS +void +btree_print_stats( + struct btree_root *root, + FILE *f); +#endif + +#endif /* _BTREE_H */ Index: xfsprogs-dev/repair/init.c =================================================================== --- xfsprogs-dev.orig/repair/init.c 2009-11-12 10:49:49.051263879 +0100 +++ xfsprogs-dev/repair/init.c 2009-11-12 10:53:01.092013310 +0100 @@ -26,7 +26,6 @@ #include "dir.h" #include "incore.h" #include "prefetch.h" -#include "radix-tree.h" #include static pthread_key_t dirbuf_key; @@ -151,5 +150,4 @@ xfs_init(libxfs_init_t *args) ts_create(); ts_init(); increase_rlimit(); - radix_tree_init(); } Index: xfsprogs-dev/repair/prefetch.c =================================================================== --- xfsprogs-dev.orig/repair/prefetch.c 2009-11-12 10:49:49.056254319 +0100 +++ xfsprogs-dev/repair/prefetch.c 2009-11-12 11:01:42.533256209 +0100 @@ -1,6 +1,7 @@ #include #include #include "avl.h" +#include "btree.h" #include "globals.h" #include "agheader.h" #include "incore.h" @@ -14,7 +15,6 @@ #include "threads.h" #include "prefetch.h" #include "progress.h" -#include "radix-tree.h" int do_prefetch = 1; @@ -129,10 +129,8 @@ pf_queue_io( pthread_mutex_lock(&args->lock); if (fsbno > args->last_bno_read) { - radix_tree_insert(&args->primary_io_queue, fsbno, bp); - if (!B_IS_INODE(flag)) - radix_tree_tag_set(&args->primary_io_queue, fsbno, 0); - else { + btree_insert(args->primary_io_queue, fsbno, bp); + if (B_IS_INODE(flag)) { args->inode_bufs_queued++; if (args->inode_bufs_queued == IO_THRESHOLD) pf_start_io_workers(args); @@ -154,7 +152,7 @@ pf_queue_io( #endif ASSERT(!B_IS_INODE(flag)); XFS_BUF_SET_PRIORITY(bp, B_DIR_META_2); - radix_tree_insert(&args->secondary_io_queue, fsbno, bp); + btree_insert(args->secondary_io_queue, fsbno, bp); } pf_start_processing(args); @@ -407,7 +405,7 @@ pf_batch_read( pf_which_t which, void *buf) { - struct radix_tree_root *queue; + struct btree_root *queue; xfs_buf_t *bplist[MAX_BUFS]; unsigned int num; off64_t first_off, last_off, next_off; @@ -415,27 +413,25 @@ pf_batch_read( int i; int inode_bufs; unsigned long fsbno; + unsigned long max_fsbno; char *pbuf; - queue = (which != PF_SECONDARY) ? &args->primary_io_queue - : &args->secondary_io_queue; + queue = (which != PF_SECONDARY) ? args->primary_io_queue + : args->secondary_io_queue; - while (radix_tree_lookup_first(queue, &fsbno) != NULL) { - - if (which != PF_META_ONLY) { - num = radix_tree_gang_lookup_ex(queue, - (void**)&bplist[0], fsbno, - fsbno + pf_max_fsbs, MAX_BUFS); - ASSERT(num > 0); - ASSERT(XFS_FSB_TO_DADDR(mp, fsbno) == - XFS_BUF_ADDR(bplist[0])); - } else { - num = radix_tree_gang_lookup_tag(queue, - (void**)&bplist[0], fsbno, - MAX_BUFS / 4, 0); - if (num == 0) - return; + while (btree_find(queue, 0, &fsbno) != NULL) { + max_fsbno = fsbno + pf_max_fsbs; + num = 0; + + bplist[0] = btree_lookup(queue, fsbno); + while (bplist[num] && num < MAX_BUFS && fsbno < max_fsbno) { + if (which != PF_META_ONLY || + !B_IS_INODE(XFS_BUF_PRIORITY(bplist[num]))) + num++; + bplist[num] = btree_lookup_next(queue, &fsbno); } + if (!num) + return; /* * do a big read if 25% of the potential buffer is useful, @@ -467,7 +463,7 @@ pf_batch_read( } for (i = 0; i < num; i++) { - if (radix_tree_delete(queue, XFS_DADDR_TO_FSB(mp, + if (btree_delete(queue, XFS_DADDR_TO_FSB(mp, XFS_BUF_ADDR(bplist[i]))) == NULL) do_error(_("prefetch corruption\n")); } @@ -570,8 +566,7 @@ pf_io_worker( return NULL; pthread_mutex_lock(&args->lock); - while (!args->queuing_done || args->primary_io_queue.height) { - + while (!args->queuing_done || !btree_is_empty(args->primary_io_queue)) { #ifdef XR_PF_TRACE pftrace("waiting to start prefetch I/O for AG %d", args->agno); #endif @@ -696,8 +691,8 @@ pf_queuing_worker( #endif pthread_mutex_lock(&args->lock); - ASSERT(args->primary_io_queue.height == 0); - ASSERT(args->secondary_io_queue.height == 0); + ASSERT(btree_is_empty(args->primary_io_queue)); + ASSERT(btree_is_empty(args->secondary_io_queue)); args->prefetch_done = 1; if (args->next_args) @@ -755,8 +750,8 @@ start_inode_prefetch( args = calloc(1, sizeof(prefetch_args_t)); - INIT_RADIX_TREE(&args->primary_io_queue, 0); - INIT_RADIX_TREE(&args->secondary_io_queue, 0); + btree_init(&args->primary_io_queue); + btree_init(&args->secondary_io_queue); if (pthread_mutex_init(&args->lock, NULL) != 0) do_error(_("failed to initialize prefetch mutex\n")); if (pthread_cond_init(&args->start_reading, NULL) != 0) @@ -835,6 +830,8 @@ cleanup_inode_prefetch( pthread_cond_destroy(&args->start_reading); pthread_cond_destroy(&args->start_processing); sem_destroy(&args->ra_count); + btree_destroy(args->primary_io_queue); + btree_destroy(args->secondary_io_queue); free(args); } Index: xfsprogs-dev/repair/prefetch.h =================================================================== --- xfsprogs-dev.orig/repair/prefetch.h 2009-11-12 10:49:49.062253827 +0100 +++ xfsprogs-dev/repair/prefetch.h 2009-11-12 10:53:01.098026017 +0100 @@ -3,7 +3,6 @@ #include #include "incore.h" -#include "radix-tree.h" extern int do_prefetch; @@ -14,8 +13,8 @@ typedef struct prefetch_args { pthread_mutex_t lock; pthread_t queuing_thread; pthread_t io_threads[PF_THREAD_COUNT]; - struct radix_tree_root primary_io_queue; - struct radix_tree_root secondary_io_queue; + struct btree_root *primary_io_queue; + struct btree_root *secondary_io_queue; pthread_cond_t start_reading; pthread_cond_t start_processing; int agno; Index: xfsprogs-dev/repair/radix-tree.c =================================================================== --- xfsprogs-dev.orig/repair/radix-tree.c 2009-11-12 10:49:49.070276497 +0100 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,805 +0,0 @@ -/* - * Copyright (C) 2001 Momchil Velikov - * Portions Copyright (C) 2001 Christoph Hellwig - * Copyright (C) 2005 SGI, Christoph Lameter - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2, or (at - * your option) any later version. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#include -#include "radix-tree.h" - -#ifndef ARRAY_SIZE -#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) -#endif - -#define RADIX_TREE_MAP_SHIFT 6 -#define RADIX_TREE_MAP_SIZE (1UL << RADIX_TREE_MAP_SHIFT) -#define RADIX_TREE_MAP_MASK (RADIX_TREE_MAP_SIZE-1) - -#ifdef RADIX_TREE_TAGS -#define RADIX_TREE_TAG_LONGS \ - ((RADIX_TREE_MAP_SIZE + BITS_PER_LONG - 1) / BITS_PER_LONG) -#endif - -struct radix_tree_node { - unsigned int count; - void *slots[RADIX_TREE_MAP_SIZE]; -#ifdef RADIX_TREE_TAGS - unsigned long tags[RADIX_TREE_MAX_TAGS][RADIX_TREE_TAG_LONGS]; -#endif -}; - -struct radix_tree_path { - struct radix_tree_node *node; - int offset; -}; - -#define RADIX_TREE_INDEX_BITS (8 /* CHAR_BIT */ * sizeof(unsigned long)) -#define RADIX_TREE_MAX_PATH (RADIX_TREE_INDEX_BITS/RADIX_TREE_MAP_SHIFT + 2) - -static unsigned long height_to_maxindex[RADIX_TREE_MAX_PATH]; - -/* - * Radix tree node cache. - */ - -#define radix_tree_node_alloc(r) ((struct radix_tree_node *) \ - calloc(1, sizeof(struct radix_tree_node))) -#define radix_tree_node_free(n) free(n) - -#ifdef RADIX_TREE_TAGS - -static inline void tag_set(struct radix_tree_node *node, unsigned int tag, - int offset) -{ - *((__uint32_t *)node->tags[tag] + (offset >> 5)) |= (1 << (offset & 31)); -} - -static inline void tag_clear(struct radix_tree_node *node, unsigned int tag, - int offset) -{ - __uint32_t *p = (__uint32_t*)node->tags[tag] + (offset >> 5); - __uint32_t m = 1 << (offset & 31); - *p &= ~m; -} - -static inline int tag_get(struct radix_tree_node *node, unsigned int tag, - int offset) -{ - return 1 & (((const __uint32_t *)node->tags[tag])[offset >> 5] >> (offset & 31)); -} - -/* - * Returns 1 if any slot in the node has this tag set. - * Otherwise returns 0. - */ -static inline int any_tag_set(struct radix_tree_node *node, unsigned int tag) -{ - int idx; - for (idx = 0; idx < RADIX_TREE_TAG_LONGS; idx++) { - if (node->tags[tag][idx]) - return 1; - } - return 0; -} - -#endif - -/* - * Return the maximum key which can be store into a - * radix tree with height HEIGHT. - */ -static inline unsigned long radix_tree_maxindex(unsigned int height) -{ - return height_to_maxindex[height]; -} - -/* - * Extend a radix tree so it can store key @index. - */ -static int radix_tree_extend(struct radix_tree_root *root, unsigned long index) -{ - struct radix_tree_node *node; - unsigned int height; -#ifdef RADIX_TREE_TAGS - char tags[RADIX_TREE_MAX_TAGS]; - int tag; -#endif - - /* Figure out what the height should be. */ - height = root->height + 1; - while (index > radix_tree_maxindex(height)) - height++; - - if (root->rnode == NULL) { - root->height = height; - goto out; - } - -#ifdef RADIX_TREE_TAGS - /* - * Prepare the tag status of the top-level node for propagation - * into the newly-pushed top-level node(s) - */ - for (tag = 0; tag < RADIX_TREE_MAX_TAGS; tag++) { - tags[tag] = 0; - if (any_tag_set(root->rnode, tag)) - tags[tag] = 1; - } -#endif - do { - if (!(node = radix_tree_node_alloc(root))) - return -ENOMEM; - - /* Increase the height. */ - node->slots[0] = root->rnode; - -#ifdef RADIX_TREE_TAGS - /* Propagate the aggregated tag info into the new root */ - for (tag = 0; tag < RADIX_TREE_MAX_TAGS; tag++) { - if (tags[tag]) - tag_set(node, tag, 0); - } -#endif - node->count = 1; - root->rnode = node; - root->height++; - } while (height > root->height); -out: - return 0; -} - -/** - * radix_tree_insert - insert into a radix tree - * @root: radix tree root - * @index: index key - * @item: item to insert - * - * Insert an item into the radix tree at position @index. - */ -int radix_tree_insert(struct radix_tree_root *root, - unsigned long index, void *item) -{ - struct radix_tree_node *node = NULL, *slot; - unsigned int height, shift; - int offset; - int error; - - /* Make sure the tree is high enough. */ - if ((!index && !root->rnode) || - index > radix_tree_maxindex(root->height)) { - error = radix_tree_extend(root, index); - if (error) - return error; - } - - slot = root->rnode; - height = root->height; - shift = (height-1) * RADIX_TREE_MAP_SHIFT; - - offset = 0; /* uninitialised var warning */ - do { - if (slot == NULL) { - /* Have to add a child node. */ - if (!(slot = radix_tree_node_alloc(root))) - return -ENOMEM; - if (node) { - node->slots[offset] = slot; - node->count++; - } else - root->rnode = slot; - } - - /* Go a level down */ - offset = (index >> shift) & RADIX_TREE_MAP_MASK; - node = slot; - slot = node->slots[offset]; - shift -= RADIX_TREE_MAP_SHIFT; - height--; - } while (height > 0); - - if (slot != NULL) - return -EEXIST; - - ASSERT(node); - node->count++; - node->slots[offset] = item; -#ifdef RADIX_TREE_TAGS - ASSERT(!tag_get(node, 0, offset)); - ASSERT(!tag_get(node, 1, offset)); -#endif - return 0; -} - -static inline void **__lookup_slot(struct radix_tree_root *root, - unsigned long index) -{ - unsigned int height, shift; - struct radix_tree_node **slot; - - height = root->height; - if (index > radix_tree_maxindex(height)) - return NULL; - - shift = (height-1) * RADIX_TREE_MAP_SHIFT; - slot = &root->rnode; - - while (height > 0) { - if (*slot == NULL) - return NULL; - - slot = (struct radix_tree_node **) - ((*slot)->slots + - ((index >> shift) & RADIX_TREE_MAP_MASK)); - shift -= RADIX_TREE_MAP_SHIFT; - height--; - } - - return (void **)slot; -} - -/** - * radix_tree_lookup_slot - lookup a slot in a radix tree - * @root: radix tree root - * @index: index key - * - * Lookup the slot corresponding to the position @index in the radix tree - * @root. This is useful for update-if-exists operations. - */ -void **radix_tree_lookup_slot(struct radix_tree_root *root, unsigned long index) -{ - return __lookup_slot(root, index); -} - -/** - * radix_tree_lookup - perform lookup operation on a radix tree - * @root: radix tree root - * @index: index key - * - * Lookup the item at the position @index in the radix tree @root. - */ -void *radix_tree_lookup(struct radix_tree_root *root, unsigned long index) -{ - void **slot; - - slot = __lookup_slot(root, index); - return slot != NULL ? *slot : NULL; -} - -/** - * raid_tree_first_key - find the first index key in the radix tree - * @root: radix tree root - * @index: where the first index will be placed - * - * Returns the first entry and index key in the radix tree @root. - */ -void *radix_tree_lookup_first(struct radix_tree_root *root, unsigned long *index) -{ - unsigned int height, shift; - struct radix_tree_node *slot; - unsigned long i; - - height = root->height; - *index = 0; - if (height == 0) - return NULL; - - shift = (height-1) * RADIX_TREE_MAP_SHIFT; - slot = root->rnode; - - for (; height > 1; height--) { - for (i = 0; i < RADIX_TREE_MAP_SIZE; i++) { - if (slot->slots[i] != NULL) - break; - } - ASSERT(i < RADIX_TREE_MAP_SIZE); - - *index |= (i << shift); - shift -= RADIX_TREE_MAP_SHIFT; - slot = slot->slots[i]; - } - for (i = 0; i < RADIX_TREE_MAP_SIZE; i++) { - if (slot->slots[i] != NULL) { - *index |= i; - return slot->slots[i]; - } - } - return NULL; -} - -#ifdef RADIX_TREE_TAGS - -/** - * radix_tree_tag_set - set a tag on a radix tree node - * @root: radix tree root - * @index: index key - * @tag: tag index - * - * Set the search tag (which must be < RADIX_TREE_MAX_TAGS) - * corresponding to @index in the radix tree. From - * the root all the way down to the leaf node. - * - * Returns the address of the tagged item. Setting a tag on a not-present - * item is a bug. - */ -void *radix_tree_tag_set(struct radix_tree_root *root, - unsigned long index, unsigned int tag) -{ - unsigned int height, shift; - struct radix_tree_node *slot; - - height = root->height; - if (index > radix_tree_maxindex(height)) - return NULL; - - shift = (height - 1) * RADIX_TREE_MAP_SHIFT; - slot = root->rnode; - - while (height > 0) { - int offset; - - offset = (index >> shift) & RADIX_TREE_MAP_MASK; - if (!tag_get(slot, tag, offset)) - tag_set(slot, tag, offset); - slot = slot->slots[offset]; - ASSERT(slot != NULL); - shift -= RADIX_TREE_MAP_SHIFT; - height--; - } - - return slot; -} - -/** - * radix_tree_tag_clear - clear a tag on a radix tree node - * @root: radix tree root - * @index: index key - * @tag: tag index - * - * Clear the search tag (which must be < RADIX_TREE_MAX_TAGS) - * corresponding to @index in the radix tree. If - * this causes the leaf node to have no tags set then clear the tag in the - * next-to-leaf node, etc. - * - * Returns the address of the tagged item on success, else NULL. ie: - * has the same return value and semantics as radix_tree_lookup(). - */ -void *radix_tree_tag_clear(struct radix_tree_root *root, - unsigned long index, unsigned int tag) -{ - struct radix_tree_path path[RADIX_TREE_MAX_PATH], *pathp = path; - struct radix_tree_node *slot; - unsigned