From owner-xfs@oss.sgi.com Thu Feb 1 11:15:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 11:15:34 -0800 (PST) X-Spam-oss-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l11JFSqw012562 for ; Thu, 1 Feb 2007 11:15:29 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id l11Ihjnc80914784; Thu, 1 Feb 2007 10:43:45 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id l11JEWmm3433507; Thu, 1 Feb 2007 13:14:32 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 2022) id 7BDE11F71F6; Thu, 1 Feb 2007 13:14:32 -0600 (CST) To: xfs-dev@sgi.com, xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 956828 - xfsqa test failures when quota and gquota options are used Message-Id: <20070201191432.7BDE11F71F6@attica.americas.sgi.com> Date: Thu, 1 Feb 2007 13:14:32 -0600 (CST) From: wkendall@sgi.com (Bill Kendall) X-archive-position: 10516 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 496 Lines: 15 Log a message for each quota file restored, not just the first one. Date: Thu Feb 1 11:13:53 PST 2007 Workarea: attica.americas.sgi.com:/data/lwork/attica1/dmfgrp/4.0_chroot/wkendall/xfs-cmds Inspected by: dgc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:220674a xfsdump/restore/content.c - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/content.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h From owner-xfs@oss.sgi.com Thu Feb 1 11:17:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 11:17:54 -0800 (PST) X-Spam-oss-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l11JHjqw013262 for ; Thu, 1 Feb 2007 11:17:45 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id l11Ik2nc80914831; Thu, 1 Feb 2007 10:46:02 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id l11JGnmm3419281; Thu, 1 Feb 2007 13:16:49 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 2022) id 858641F71F6; Thu, 1 Feb 2007 13:16:49 -0600 (CST) To: xfs-dev@sgi.com, xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 959172 - check file size at dump time rather than only during initial scan Message-Id: <20070201191649.858641F71F6@attica.americas.sgi.com> Date: Thu, 1 Feb 2007 13:16:49 -0600 (CST) From: wkendall@sgi.com (Bill Kendall) X-archive-position: 10517 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 1019 Lines: 22 When using -z, check a file's size against the max dump file size just before dumping the file, rather than only during the initial scan. Date: Thu Feb 1 11:16:27 PST 2007 Workarea: attica.americas.sgi.com:/data/lwork/attica1/dmfgrp/4.0_chroot/wkendall/xfs-cmds Inspected by: bnaujok The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:220675a xfsdump/dump/content.c - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/content.c.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfsdump/dump/inomap.c - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/inomap.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h xfsdump/common/hsmapi.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/hsmapi.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsdump/common/hsmapi.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/hsmapi.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h From owner-xfs@oss.sgi.com Thu Feb 1 11:20:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 11:20:19 -0800 (PST) X-Spam-oss-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l11JKBqw014071 for ; Thu, 1 Feb 2007 11:20:14 -0800 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id l11J3dDW023876 for ; Thu, 1 Feb 2007 13:03:39 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id l11IWmnc80912386; Thu, 1 Feb 2007 10:32:48 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id l11J3amm3430598; Thu, 1 Feb 2007 13:03:36 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 2022) id 171991F71F6; Thu, 1 Feb 2007 13:03:35 -0600 (CST) To: xfs-dev@sgi.com, xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 959167 - xfsdump uses getopt's optopt variable incorrectly Message-Id: <20070201190336.171991F71F6@attica.americas.sgi.com> Date: Thu, 1 Feb 2007 13:03:35 -0600 (CST) From: wkendall@sgi.com (Bill Kendall) X-archive-position: 10519 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 1909 Lines: 35 xfsdump uses the optopt variable from getopt incorrectly. It assumes that the value is set to the current option being processed, when in fact it is only set when getopt encounters an unknown option. Thanks to Kouta Ooizumi. Date: Thu Feb 1 11:02:45 PST 2007 Workarea: attica.americas.sgi.com:/data/lwork/attica1/dmfgrp/4.0_chroot/wkendall/xfs-cmds Inspected by: bnaujok The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:220672a xfsdump/dump/content.c - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/content.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h xfsdump/restore/content.c - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/restore/content.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfsdump/common/global.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/global.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsdump/common/drive.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/drive.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsdump/common/mlog.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/mlog.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsdump/common/media.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/media.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsdump/common/drive_scsitape.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/drive_scsitape.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsdump/common/drive_minrmt.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/drive_minrmt.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsdump/common/main.c - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/main.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h From owner-xfs@oss.sgi.com Thu Feb 1 11:20:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 11:20:18 -0800 (PST) X-Spam-oss-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l11JKAqw014062 for ; Thu, 1 Feb 2007 11:20:11 -0800 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id l11JCJDW025224 for ; Thu, 1 Feb 2007 13:12:19 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id l11IfTnc80910120; Thu, 1 Feb 2007 10:41:29 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id l11JCHmm3428418; Thu, 1 Feb 2007 13:12:17 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 2022) id 42CE61F71F6; Thu, 1 Feb 2007 13:12:17 -0600 (CST) To: xfs-dev@sgi.com, xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 959168 - xfsdump's logging facility not initialized early enough Message-Id: <20070201191217.42CE61F71F6@attica.americas.sgi.com> Date: Thu, 1 Feb 2007 13:12:17 -0600 (CST) From: wkendall@sgi.com (Bill Kendall) X-archive-position: 10518 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 968 Lines: 22 Initialize xfsdump's logging facility earlier during initialization. Thanks to Kouta Ooizumi. Date: Thu Feb 1 11:10:50 PST 2007 Workarea: attica.americas.sgi.com:/data/lwork/attica1/dmfgrp/4.0_chroot/wkendall/xfs-cmds Inspected by: dgc The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:220673a xfsdump/common/stream.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/stream.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsdump/common/mlog.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/mlog.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsdump/common/mlog.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/mlog.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsdump/common/main.c - 1.33 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/common/main.c.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h From owner-xfs@oss.sgi.com Thu Feb 1 11:25:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 11:26:02 -0800 (PST) X-Spam-oss-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l11JPrqw015772 for ; Thu, 1 Feb 2007 11:25:54 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id l11Is9nc80921770; Thu, 1 Feb 2007 10:54:10 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id l11JOvmm3431964; Thu, 1 Feb 2007 13:24:57 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 2022) id 8A1D61F71F6; Thu, 1 Feb 2007 13:24:57 -0600 (CST) To: xfs-dev@sgi.com, xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 960742 - bump xfsdump version to 2.2.44 Message-Id: <20070201192457.8A1D61F71F6@attica.americas.sgi.com> Date: Thu, 1 Feb 2007 13:24:57 -0600 (CST) From: wkendall@sgi.com (Bill Kendall) X-archive-position: 10520 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 608 Lines: 17 Bump xfsdump version to 2.2.44 and document changes. Date: Thu Feb 1 11:24:34 PST 2007 Workarea: attica.americas.sgi.com:/data/lwork/attica1/dmfgrp/4.0_chroot/wkendall/xfs-cmds Inspected by: kfr The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:220677a xfsdump/VERSION - 1.85 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/VERSION.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h xfsdump/doc/CHANGES - 1.99 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/doc/CHANGES.diff?r1=text&tr1=1.99&r2=text&tr2=1.98&f=h From owner-xfs@oss.sgi.com Thu Feb 1 11:35:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 11:35:20 -0800 (PST) X-Spam-oss-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l11JZBqw017261 for ; Thu, 1 Feb 2007 11:35:12 -0800 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id l11JLADW026591 for ; Thu, 1 Feb 2007 13:21:10 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id l11IoLnc80919886; Thu, 1 Feb 2007 10:50:21 -0800 (PST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id l11JL9mm3431856; Thu, 1 Feb 2007 13:21:09 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 2022) id 13F9F1F71F6; Thu, 1 Feb 2007 13:21:09 -0600 (CST) To: xfs-dev@sgi.com, xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 960730 - incremental xfsdump can skip modified/new files Message-Id: <20070201192109.13F9F1F71F6@attica.americas.sgi.com> Date: Thu, 1 Feb 2007 13:21:09 -0600 (CST) From: wkendall@sgi.com (Bill Kendall) X-archive-position: 10521 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 710 Lines: 19 Issue a sync call before doing the initial inode scan so that any inode changes in the inode cache are reflected in the bulk stat calls. This is necessary for incremental dumps to work properly (i.e. not skip files) so that all inodes changed before the dump time are included in the dump. Date: Thu Feb 1 11:20:37 PST 2007 Workarea: attica.americas.sgi.com:/data/lwork/attica1/dmfgrp/4.0_chroot/wkendall/xfs-cmds Inspected by: kfr The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:220676a xfsdump/dump/inomap.c - 1.33 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/dump/inomap.c.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h From owner-xfs@oss.sgi.com Thu Feb 1 21:24:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 21:24:21 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l125OCqw006015 for ; Thu, 1 Feb 2007 21:24:14 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA02793; Fri, 2 Feb 2007 16:23:11 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 4DD7758FF653; Fri, 2 Feb 2007 16:23:11 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 959267 - bad clientid during log replay of snapshot image Message-Id: <20070202052311.4DD7758FF653@chook.melbourne.sgi.com> Date: Fri, 2 Feb 2007 16:23:11 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10530 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2285 Lines: 50 Ensure a frozen filesystem has a clean log before writing the dummy record. The current Linux XFS freeze code is a mess. We flush the metadata buffers out while we are still allowing new transactions to start and then fail to flush the dirty buffers back out before writing the unmount and dummy records to the log. This leads to problems when the frozen filesystem is used for snapshots - we do log recovery on a readonly image and often it appears that the log image in the snapshot is not correct. Hence we end up with hangs, oops and mount failures when trying to mount a snapshot image that has been created when the filesystem has not been correctly frozen. To fix this, we need to move th metadata flush to after we wait for all current transactions to complete in teh second stage of the freeze. This means that when we write the final log records, the log should be clean and recovery should never occur on a snapshot image created from a frozen filesystem. Date: Fri Feb 2 16:22:20 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: donaldd The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28010a fs/xfs/xfs_vfsops.c - 1.514 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.514&r2=text&tr2=1.513&f=h - Push xfs_quiesce_fs() down into xfs_freeze() so it occurs after we've blocked new transactions and waited for all the currently running transactions to complete. hence we should have a clean log before we write the unmount and dummy records into the log. fs/xfs/linux-2.6/xfs_vfs.h - 1.68 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h - Add definition of SYNC_DIO_WAIT for telling the sync code to wait for direct I/O to complete. fs/xfs/linux-2.6/xfs_super.c - 1.376 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.376&r2=text&tr2=1.375&f=h - After the writes are frozen, simply flush out the data and wait for all data I/O (including direct I/O) to complete. Don't bother flushing the metadata out - we still have active transactions at this point. From owner-xfs@oss.sgi.com Thu Feb 1 21:33:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 21:33:56 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l125Xmqw007348 for ; Thu, 1 Feb 2007 21:33:50 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA03079; Fri, 2 Feb 2007 16:32:48 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 94D5658FF653; Fri, 2 Feb 2007 16:32:48 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 960408 - dmapi bulkstat returns incorrect number of blocks used Message-Id: <20070202053248.94D5658FF653@chook.melbourne.sgi.com> Date: Fri, 2 Feb 2007 16:32:48 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10531 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 606 Lines: 20 DMAPI bulkstat block count units incorrect. Return dt_blocks in units of 512 byte blocks instead of filesystem blocks. Date: Fri Feb 2 16:32:12 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28011a fs/xfs/dmapi/xfs_dm.c - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h - Return dt_blocks in units of 512 byte blocks instead of filesystem blocks. From owner-xfs@oss.sgi.com Thu Feb 1 21:41:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Feb 2007 21:41:53 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, J_CHICKENPOX_36 autolearn=no version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l125fkqw008631 for ; Thu, 1 Feb 2007 21:41:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA03219; Fri, 2 Feb 2007 16:40:47 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l125ek7Y110583035; Fri, 2 Feb 2007 16:40:46 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l125ei80110563597; Fri, 2 Feb 2007 16:40:44 +1100 (AEDT) Date: Fri, 2 Feb 2007 16:40:44 +1100 From: David Chinner To: xfs-dev@sgi.com Cc: xfs@oss.sgi.com Subject: Review: Don't use kmap() in xfs_iozero(). Message-ID: <20070202054044.GO33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 10532 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1451 Lines: 58 kmap is inefficient and does scale well. kmap_atomic() is a better choice. Use the generic wrapper function instead of open coding the kmap-memset-dcache flush-kumap stuff. Suggested by Andrew Morton. Comments? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_lrw.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_lrw.c 2007-01-31 13:56:12.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_lrw.c 2007-01-31 14:19:50.379179841 +1100 @@ -138,7 +138,6 @@ xfs_iozero( unsigned bytes; struct page *page; struct address_space *mapping; - char *kaddr; int status; mapping = ip->i_mapping; @@ -156,15 +155,13 @@ xfs_iozero( if (!page) break; - kaddr = kmap(page); status = mapping->a_ops->prepare_write(NULL, page, offset, offset + bytes); - if (status) { + if (status) goto unlock; - } - memset((void *) (kaddr + offset), 0, bytes); - flush_dcache_page(page); + memclear_highpage_flush(page, (unsigned int)offset, bytes); + status = mapping->a_ops->commit_write(NULL, page, offset, offset + bytes); if (!status) { @@ -175,7 +172,6 @@ xfs_iozero( } unlock: - kunmap(page); unlock_page(page); page_cache_release(page); if (status) From owner-xfs@oss.sgi.com Fri Feb 2 04:24:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Feb 2007 04:24:40 -0800 (PST) X-Spam-oss-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l12COWqw007203 for ; Fri, 2 Feb 2007 04:24:33 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HCws3-00069l-Tu; Fri, 02 Feb 2007 11:46:23 +0000 Date: Fri, 2 Feb 2007 11:46:23 +0000 From: Christoph Hellwig To: David Chinner Cc: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: freezing sometimes leaves the log dirty Message-ID: <20070202114623.GA23187@infradead.org> References: <20070130220326.GM33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070130220326.GM33919298@melbourne.sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10533 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 2539 Lines: 78 On Wed, Jan 31, 2007 at 09:03:26AM +1100, David Chinner wrote: > - if (unlikely(sb->s_frozen == SB_FREEZE_WRITE)) > - flags = SYNC_QUIESCE; > - else > + if (unlikely(sb->s_frozen == SB_FREEZE_WRITE)) { > + /* > + * First stage of freeze - no more writers will make progress > + * now we are here, so we flush delwri and delalloc buffers > + * here, then wait for all I/O to complete. Data is frozen at > + * that point. Metadata is not frozen, transactions can still > + * occur here so don't bother flushing the buftarg (i.e > + * SYNC_QUIESCE) because it'll just get dirty again. > + */ > + flags = SYNC_FSDATA | SYNC_DELWRI | SYNC_WAIT | SYNC_DIO_WAIT; > + } else You remove all uses of SYNC_QUIESCE in this patch, so please kill the definition aswell. > + * SYNC_DIO_WAIT - The caller wants us to wait for all direct I/Os > + * as well to ensure all data I/O completes before we > + * return. Forms the drain side of the write barrier needed > + * to safely quiesce the filesystem. > * > */ > /*ARGSUSED*/ > @@ -892,10 +896,7 @@ xfs_sync( > { > xfs_mount_t *mp = XFS_BHVTOM(bdp); > > - if (unlikely(flags == SYNC_QUIESCE)) > - return xfs_quiesce_fs(mp); > - else > - return xfs_syncsub(mp, flags, NULL); > + return xfs_syncsub(mp, flags, NULL); > } > > /* > @@ -1181,6 +1182,12 @@ xfs_sync_inodes( > } > > } > + /* > + * When freezing, we need to wait ensure direct I/O is complete > + * as well to ensure all data modification is complete here > + */ > + if (flags & SYNC_DIO_WAIT) > + vn_iowait(vp); vn_iowait waits for v_iocount decrementing to zero. We use v_iocount for tracking ioend structures that are used both for buffered and direct I/O. Because of that the flag should probably be SYNC_IOWAIT and the comment updated to reflect this. > +/* > + * Second stage of a freeze. The data is already frozen, now we have to take > + * care of the metadata. New transactions are already blocked, so we need to > + * wait for any remaining transactions to drain out before proceding. > + */ > STATIC void > xfs_freeze( > bhv_desc_t *bdp) > { > xfs_mount_t *mp = XFS_BHVTOM(bdp); > > + /* wait for all modifications to complete */ > while (atomic_read(&mp->m_active_trans) > 0) > delay(100); > > + /* flush inodes and push all remaining buffers out to disk */ > + xfs_quiesce_fs(mp); > + > + BUG_ON(atomic_read(&mp->m_active_trans) > 0); > + xfs_vfsops.c is considered common code, so you should probably use ASSERT here, not BUG_ON. From owner-xfs@oss.sgi.com Fri Feb 2 04:24:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Feb 2007 04:25:21 -0800 (PST) X-Spam-oss-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_20, J_CHICKENPOX_36 autolearn=no version=3.2.0-pre1-r497472 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l12COlqw007246 for ; Fri, 2 Feb 2007 04:24:48 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HCwu6-0006Ce-EX; Fri, 02 Feb 2007 11:48:30 +0000 Date: Fri, 2 Feb 2007 11:48:30 +0000 From: Christoph Hellwig To: David Chinner Cc: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Don't use kmap() in xfs_iozero(). Message-ID: <20070202114830.GB23187@infradead.org> References: <20070202054044.GO33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202054044.GO33919298@melbourne.sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10534 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 495 Lines: 14 On Fri, Feb 02, 2007 at 04:40:44PM +1100, David Chinner wrote: > kmap is inefficient and does scale well. kmap_atomic() is a better > choice. Use the generic wrapper function instead of open coding the > kmap-memset-dcache flush-kumap stuff. Suggested by Andrew Morton. > > Comments? Looks good. > + memclear_highpage_flush(page, (unsigned int)offset, bytes); Do you need the cast here? An unsigned long should be automatically demoted to an unsigned int when passing it as an argument. From owner-xfs@oss.sgi.com Fri Feb 2 05:40:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Feb 2007 05:40:55 -0800 (PST) X-Spam-oss-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_20, J_CHICKENPOX_36 autolearn=no version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l12Degqw017508 for ; Fri, 2 Feb 2007 05:40:44 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA14594; Sat, 3 Feb 2007 00:39:43 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l12Ddg7Y111988747; Sat, 3 Feb 2007 00:39:42 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l12DdfwH111900500; Sat, 3 Feb 2007 00:39:41 +1100 (AEDT) Date: Sat, 3 Feb 2007 00:39:41 +1100 From: David Chinner To: Christoph Hellwig Cc: David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Don't use kmap() in xfs_iozero(). Message-ID: <20070202133941.GW33919298@melbourne.sgi.com> References: <20070202054044.GO33919298@melbourne.sgi.com> <20070202114830.GB23187@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202114830.GB23187@infradead.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 10535 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 863 Lines: 27 On Fri, Feb 02, 2007 at 11:48:30AM +0000, Christoph Hellwig wrote: > On Fri, Feb 02, 2007 at 04:40:44PM +1100, David Chinner wrote: > > kmap is inefficient and does scale well. kmap_atomic() is a better > > choice. Use the generic wrapper function instead of open coding the > > kmap-memset-dcache flush-kumap stuff. Suggested by Andrew Morton. > > > > Comments? > > Looks good. > > > + memclear_highpage_flush(page, (unsigned int)offset, bytes); > > Do you need the cast here? An unsigned long should be automatically > demoted to an unsigned int when passing it as an argument. Even on 64 bit platforms? I just added an explicit cast as a matter of avoiding potential gcc warnings on other platforms/compiler versions. Maybe I'm just being paranoid and I can remove it? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Feb 2 06:08:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Feb 2007 06:08:17 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l12E86qw020622 for ; Fri, 2 Feb 2007 06:08:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA15252; Sat, 3 Feb 2007 01:07:08 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l12E777Y112086427; Sat, 3 Feb 2007 01:07:07 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l12E76FB112045480; Sat, 3 Feb 2007 01:07:06 +1100 (AEDT) Date: Sat, 3 Feb 2007 01:07:06 +1100 From: David Chinner To: Christoph Hellwig Cc: David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: freezing sometimes leaves the log dirty Message-ID: <20070202140706.GX33919298@melbourne.sgi.com> References: <20070130220326.GM33919298@melbourne.sgi.com> <20070202114623.GA23187@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202114623.GA23187@infradead.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 10536 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 7989 Lines: 193 On Fri, Feb 02, 2007 at 11:46:23AM +0000, Christoph Hellwig wrote: > On Wed, Jan 31, 2007 at 09:03:26AM +1100, David Chinner wrote: > > - if (unlikely(sb->s_frozen == SB_FREEZE_WRITE)) > > - flags = SYNC_QUIESCE; > > - else > > + if (unlikely(sb->s_frozen == SB_FREEZE_WRITE)) { > > + /* > > + * First stage of freeze - no more writers will make progress > > + * now we are here, so we flush delwri and delalloc buffers > > + * here, then wait for all I/O to complete. Data is frozen at > > + * that point. Metadata is not frozen, transactions can still > > + * occur here so don't bother flushing the buftarg (i.e > > + * SYNC_QUIESCE) because it'll just get dirty again. > > + */ > > + flags = SYNC_FSDATA | SYNC_DELWRI | SYNC_WAIT | SYNC_DIO_WAIT; > > + } else > > You remove all uses of SYNC_QUIESCE in this patch, so please kill the > definition aswell. Yup, didn't think of that. > > + /* > > + * When freezing, we need to wait ensure direct I/O is complete > > + * as well to ensure all data modification is complete here > > + */ > > + if (flags & SYNC_DIO_WAIT) > > + vn_iowait(vp); > > vn_iowait waits for v_iocount decrementing to zero. We use v_iocount > for tracking ioend structures that are used both for buffered and direct > I/O. Because of that the flag should probably be SYNC_IOWAIT and the comment > updated to reflect this. Ok, that's probably a better reflection of what the code does. We've already waited for all buffered I/O via the SYNC_WAIT flag, so I was only really thinking about the direct I/o case here. > > +/* > > + * Second stage of a freeze. The data is already frozen, now we have to take > > + * care of the metadata. New transactions are already blocked, so we need to > > + * wait for any remaining transactions to drain out before proceding. > > + */ > > STATIC void > > xfs_freeze( > > bhv_desc_t *bdp) > > { > > xfs_mount_t *mp = XFS_BHVTOM(bdp); > > > > + /* wait for all modifications to complete */ > > while (atomic_read(&mp->m_active_trans) > 0) > > delay(100); > > > > + /* flush inodes and push all remaining buffers out to disk */ > > + xfs_quiesce_fs(mp); > > + > > + BUG_ON(atomic_read(&mp->m_active_trans) > 0); > > + > > xfs_vfsops.c is considered common code, so you should probably use > ASSERT here, not BUG_ON. good catch. Patch below cleans all this up and also fixes the 2.4 tree as well. BTW, i think further cleanup in xfs_quiesce_fs() can be done - that flush loop looks redundant - neither Irix nor 2.4 linux need it, and I can't see why it would be needed on 2.6. It looks to me like it was trying to fix the problem I'm fixing right now. I'll look into it further at some point... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.4/xfs_super.c | 8 +++----- fs/xfs/linux-2.4/xfs_vfs.h | 2 +- fs/xfs/linux-2.6/xfs_super.c | 2 +- fs/xfs/linux-2.6/xfs_vfs.h | 3 +-- fs/xfs/xfs_vfsops.c | 17 +++++++++-------- 5 files changed, 15 insertions(+), 17 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.4/xfs_super.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.4/xfs_super.c 2007-02-02 16:35:36.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.4/xfs_super.c 2007-02-03 00:59:00.453115972 +1100 @@ -669,13 +669,11 @@ struct super_block *freeze_bdev(struct b wmb(); /* Flush the refcache */ - bhv_vfs_sync(vfsp, SYNC_REFCACHE | SYNC_WAIT, NULL);; + bhv_vfs_sync(vfsp, SYNC_REFCACHE | SYNC_WAIT, NULL); /* Flush delalloc and delwri data */ - bhv_vfs_sync(vfsp, SYNC_DELWRI | SYNC_WAIT, NULL);; - - /* Flush out everything to it's normal place */ - bhv_vfs_sync(vfsp, SYNC_QUIESCE, NULL); + bhv_vfs_sync(vfsp, + SYNC_FSDATA|SYNC_DELWRI|SYNC_WAIT|SYNC_IOWAIT, NULL); /* Pause transaction subsystem */ vfsp->vfs_frozen = SB_FREEZE_TRANS; Index: 2.6.x-xfs-new/fs/xfs/linux-2.4/xfs_vfs.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.4/xfs_vfs.h 2007-01-16 10:54:15.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.4/xfs_vfs.h 2007-02-03 00:51:38.255434540 +1100 @@ -92,7 +92,7 @@ typedef enum { #define SYNC_FSDATA 0x0020 /* flush fs data (e.g. superblocks) */ #define SYNC_REFCACHE 0x0040 /* prune some of the nfs ref cache */ #define SYNC_REMOUNT 0x0080 /* remount readonly, no dummy LRs */ -#define SYNC_QUIESCE 0x0100 /* quiesce fileystem for a snapshot */ +#define SYNC_IOWAIT 0x0100 /* wait for all I/O to complete */ #define SHUTDOWN_META_IO_ERROR 0x0001 /* write attempt to metadata failed */ #define SHUTDOWN_LOG_IO_ERROR 0x0002 /* write attempt to the log failed */ Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_super.c 2007-02-02 16:35:36.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_super.c 2007-02-03 00:59:03.236749054 +1100 @@ -674,7 +674,7 @@ xfs_fs_sync_super( * occur here so don't bother flushing the buftarg (i.e * SYNC_QUIESCE) because it'll just get dirty again. */ - flags = SYNC_FSDATA | SYNC_DELWRI | SYNC_WAIT | SYNC_DIO_WAIT; + flags = SYNC_FSDATA | SYNC_DELWRI | SYNC_WAIT | SYNC_IOWAIT; } else flags = SYNC_FSDATA | (wait ? SYNC_WAIT : 0); Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_vfs.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_vfs.h 2007-02-02 16:35:02.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_vfs.h 2007-02-03 00:51:41.638988060 +1100 @@ -91,8 +91,7 @@ typedef enum { #define SYNC_FSDATA 0x0020 /* flush fs data (e.g. superblocks) */ #define SYNC_REFCACHE 0x0040 /* prune some of the nfs ref cache */ #define SYNC_REMOUNT 0x0080 /* remount readonly, no dummy LRs */ -#define SYNC_QUIESCE 0x0100 /* quiesce fileystem for a snapshot */ -#define SYNC_DIO_WAIT 0x0200 /* wait for direct I/O to complete */ +#define SYNC_IOWAIT 0x0100 /* wait for all I/O to complete */ #define SHUTDOWN_META_IO_ERROR 0x0001 /* write attempt to metadata failed */ #define SHUTDOWN_LOG_IO_ERROR 0x0002 /* write attempt to the log failed */ Index: 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vfsops.c 2007-02-02 16:35:36.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_vfsops.c 2007-02-03 00:49:10.946876638 +1100 @@ -881,10 +881,10 @@ xfs_statvfs( * this by simply making sure the log gets flushed * if SYNC_BDFLUSH is set, and by actually writing it * out otherwise. - * SYNC_DIO_WAIT - The caller wants us to wait for all direct I/Os - * as well to ensure all data I/O completes before we - * return. Forms the drain side of the write barrier needed - * to safely quiesce the filesystem. + * SYNC_IOWAIT - The caller wants us to wait for all data I/O to complete + * before we return (including direct I/O). Forms the drain + * side of the write barrier needed to safely quiesce the + * filesystem. * */ /*ARGSUSED*/ @@ -1183,10 +1183,11 @@ xfs_sync_inodes( } /* - * When freezing, we need to wait ensure direct I/O is complete - * as well to ensure all data modification is complete here + * When freezing, we need to wait ensure all I/O (including direct + * I/O) is complete to ensure no further data modification can take + * place after this point */ - if (flags & SYNC_DIO_WAIT) + if (flags & SYNC_IOWAIT) vn_iowait(vp); if (flags & SYNC_BDFLUSH) { @@ -1984,7 +1985,7 @@ xfs_freeze( /* flush inodes and push all remaining buffers out to disk */ xfs_quiesce_fs(mp); - BUG_ON(atomic_read(&mp->m_active_trans) > 0); + ASSERT(atomic_read(&mp->m_active_trans) == 0); /* Push the superblock and write an unmount record */ xfs_log_unmount_write(mp); From owner-xfs@oss.sgi.com Fri Feb 2 08:50:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Feb 2007 08:50:22 -0800 (PST) X-Spam-oss-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l12GoDqw014528 for ; Fri, 2 Feb 2007 08:50:15 -0800 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id l12GdxDW001507 for ; Fri, 2 Feb 2007 10:39:59 -0600 Received: from lab41.emea.sgi.com (lab41.emea.sgi.com [144.253.75.41]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id l12GfEk6022797 for ; Fri, 2 Feb 2007 08:41:14 -0800 Received: by lab41.emea.sgi.com (Postfix, from userid 1000) id 37298576B9; Fri, 2 Feb 2007 16:57:09 +0000 (GMT) To: xfs@oss.sgi.com Subject: TAKE 960788 - Fix callers of xfs_iozero() to zero the correct range. Message-Id: <20070202165709.37298576B9@lab41.emea.sgi.com> Date: Fri, 2 Feb 2007 16:57:09 +0000 (GMT) From: lachlan@lab41.emea.sgi.com (Lachlan McIlroy) X-archive-position: 10537 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@lab41.emea.sgi.com Precedence: bulk X-list: xfs Content-Length: 1120 Lines: 27 Fix callers of xfs_iozero() to zero the correct range. The problem is the two callers of xfs_iozero() are rounding out the range to be zeroed to the end of a fsb and in some cases this extends past the new eof. The call to commit_write() in xfs_iozero() will cause the Linux inode's file size to be set too high. Date: Sat Feb 3 03:36:02 AEDT 2007 Workarea: vpn-emea-sw-emea-160-1.emea.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: dgc Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28013a fs/xfs/xfs_inode.c - 1.458 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.458&r2=text&tr2=1.457&f=h fs/xfs/linux-2.6/xfs_lrw.h - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.h.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h fs/xfs/linux-2.6/xfs_lrw.c - 1.254 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.254&r2=text&tr2=1.253&f=h - Fix callers of xfs_iozero() to zero the correct range. From owner-xfs@oss.sgi.com Fri Feb 2 10:07:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Feb 2007 10:07:18 -0800 (PST) X-Spam-oss-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l12I79qw026205 for ; Fri, 2 Feb 2007 10:07:12 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HD2ne-0003kK-Iz; Fri, 02 Feb 2007 18:06:14 +0000 Date: Fri, 2 Feb 2007 18:06:14 +0000 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Don't use kmap() in xfs_iozero(). Message-ID: <20070202180614.GA13938@infradead.org> References: <20070202054044.GO33919298@melbourne.sgi.com> <20070202114830.GB23187@infradead.org> <20070202133941.GW33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202133941.GW33919298@melbourne.sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10538 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 420 Lines: 9 On Sat, Feb 03, 2007 at 12:39:41AM +1100, David Chinner wrote: > Even on 64 bit platforms? I just added an explicit cast as a matter > of avoiding potential gcc warnings on other platforms/compiler > versions. Maybe I'm just being paranoid and I can remove it? Yes, it's fine on 64bit platforms aswell - I just built my equivalent buffer.c changes on 64bit powerpc and we have lots of similar cases all over the tree. From owner-xfs@oss.sgi.com Sat Feb 3 10:25:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 03 Feb 2007 10:25:16 -0800 (PST) X-Spam-oss-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l13IPAqw009923 for ; Sat, 3 Feb 2007 10:25:11 -0800 Received: by ug-out-1314.google.com with SMTP id a2so1034036ugf for ; Sat, 03 Feb 2007 10:24:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rVl4bE434eUJ7CPil5AxpkChzeGkK/bFcw8Bsa1OTsc3xN/l8tFxCmNFs5iZk1JmiW8W23Va3NOpwShC8EHyzF9WHfaS5GqCyjsPKxalAVT514i3MCVp53VLKmHPOxOBG9G6bhCHeJb0m+7BOB8mBWemcmXB3HSyumn70WGvXQY= Received: by 10.78.146.11 with SMTP id t11mr886246hud.1170525569294; Sat, 03 Feb 2007 09:59:29 -0800 (PST) Received: by 10.78.177.2 with HTTP; Sat, 3 Feb 2007 09:59:29 -0800 (PST) Message-ID: Date: Sat, 3 Feb 2007 18:59:29 +0100 From: "KE Liew" To: xfs@oss.sgi.com Subject: bad magic and dubious inode MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 10546 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ke.liew@gmail.com Precedence: bulk X-list: xfs Content-Length: 1993 Lines: 73 Hello, It's been a great day, and this is the situation. Files were being transfered from one hdd to another, SATA to IDE, and BANG and error occured, can't remember exactly what, but I had to umount it. Successful, and ran xfs_check ==================== eXiStEnCe:~# xfs_check -s /dev/hdb bad magic # 0 in inobt block 15/916145 ==================== Doesn't look good at all. I attempted the famous xfs_repair :) ==================== eXiStEnCe:~# xfs_repair -n /dev/hdb Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... bad magic # 0 in inobt block 15/916145 dubious inode btree block header 15/916145 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting. ==================== As you can see, it's almost dead? I haven't mount it yet, so I hope it's all safe and cool. What should be the next step for me to take? Kwang From owner-xfs@oss.sgi.com Sat Feb 3 11:05:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 03 Feb 2007 11:05:25 -0800 (PST) X-Spam-oss-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l13J5Hqw015000 for ; Sat, 3 Feb 2007 11:05:19 -0800 Received: (qmail 9766 invoked by uid 510); 3 Feb 2007 19:37:43 +0100 Received: from 139.165.123.213 by serv108.segi.ulg.ac.be (envelope-from , uid 501) with qmail-scanner-1.25 (clamdscan: 0.88.6/2517. Clear:RC:1(139.165.123.213):. Processed in 0.028574 secs); 03 Feb 2007 18:37:43 -0000 Received: from unknown (HELO ulg.ac.be) ([139.165.123.213]) (envelope-sender ) by serv108.segi.ulg.ac.be (qmail-ldap-1.03) with SMTP for ; 3 Feb 2007 19:37:43 +0100 Received: by ulg.ac.be (nbSMTP-1.00) for uid 1000 wildcat@espix.org; Sat, 3 Feb 2007 19:37:23 +0100 (CET) Date: Sat, 3 Feb 2007 19:37:23 +0100 From: wildcat To: xfs@oss.sgi.com Subject: XFS "no space left" problem Message-ID: <20070203183723.GA1652@dunno.espix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 10547 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wildcat@espix.org Precedence: bulk X-list: xfs Content-Length: 2308 Lines: 84 Hi dear list, I recently migrated a 1.3Tbyte partition from reiserfs to XFS. As the 1.3Tb partition was full, my idea was to shrink reiserfs partition of 100Gig at a time, and then grow the XFS one. This has been working since 1.1To for XFS partition. Now I'm in the following situation: /dev/mapper/crypt-data 1.2T 1.1T 134G 89% /jail2 dunno jail2 # touch a dunno jail2 # touch b touch: cannot touch `b': No space left on device dunno jail2 # From there if I delete 'a', I could create a file of any size. but then will be running again into the "no space left". From here, some people told me of an inodes problem, that I checked first: /dev/mapper/crypt-data 561850144 158335 561691809 1% /jail2 is outputing from df -i. umount/remount of the partition doesn't change anything. here are some information about the filesystem details: dunno jail2 # xfs_info /jail2 meta-data=/dev/crypt/data isize=256 agcount=188, agsize=1638400 blks = sectsz=512 attr=0 data = bsize=4096 blocks=306708480, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=12800, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 dunno / # xfs_db /dev/crypt/data xfs_db> frag actual 140099, ideal 134926, fragmentation factor 3.69% xfs_db> freesp from to extents blocks pct 1 1 801 801 0.00 2 3 2 5 0.00 32 63 2 89 0.00 128 255 3 517 0.00 256 511 4 1676 0.00 512 1023 5 3776 0.01 1024 2047 7 10765 0.03 262144 524287 23 9200216 26.21 1048576 1638400 16 25888649 73.74 xfs_db> I can't think of a Fix solution from here and I'm stuck. As this box is in production and remotely managed; Go to the place, take the hard drives and backup/restore is not a solution. Any help/comment/fix/idea would be very appreciated. Any additionnal information you need could be asked :) TIA, Best regards, wildcat From owner-xfs@oss.sgi.com Sat Feb 3 15:39:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 03 Feb 2007 15:39:38 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l13NdVqw029755 for ; Sat, 3 Feb 2007 15:39:33 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA29087; Sun, 4 Feb 2007 10:38:31 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l13NcT7Y112748522; Sun, 4 Feb 2007 10:38:30 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l13NcS70112175756; Sun, 4 Feb 2007 10:38:28 +1100 (AEDT) Date: Sun, 4 Feb 2007 10:38:28 +1100 From: David Chinner To: wildcat Cc: xfs@oss.sgi.com Subject: Re: XFS "no space left" problem Message-ID: <20070203233828.GD44411608@melbourne.sgi.com> References: <20070203183723.GA1652@dunno.espix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070203183723.GA1652@dunno.espix.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 10548 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2584 Lines: 72 On Sat, Feb 03, 2007 at 07:37:23PM +0100, wildcat wrote: > Hi dear list, > > > I recently migrated a 1.3Tbyte partition from reiserfs to XFS. > As the 1.3Tb partition was full, my idea was to shrink reiserfs > partition of 100Gig at a time, and then grow the XFS one. So you've filled up the lower terabyte of the partition before you added the space above 1TB. The problem is almost certainly going to be that there's no room left to allocate inodes below the 1TB mark (32 bit inode filesystem) because all that space is taken up by data.... > dunno jail2 # xfs_info /jail2 > meta-data=/dev/crypt/data isize=256 agcount=188, > agsize=1638400 blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=306708480, > imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=12800, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > dunno / # xfs_db /dev/crypt/data > xfs_db> frag > actual 140099, ideal 134926, fragmentation factor 3.69% > xfs_db> freesp > from to extents blocks pct > 1 1 801 801 0.00 > 2 3 2 5 0.00 > 32 63 2 89 0.00 > 128 255 3 517 0.00 > 256 511 4 1676 0.00 > 512 1023 5 3776 0.01 > 1024 2047 7 10765 0.03 > 262144 524287 23 9200216 26.21 > 1048576 1638400 16 25888649 73.74 > xfs_db> Mostly large blocks. I bet they are all in AGs above the 1TB mark. One thing you can do is look at the freespace per AG: # for ag in `seq 0 1 188`; do > echo freespace in AG $ag > xfs_db ­r -c "freesp -s -a $ag" /dev/crypt/data | grep "total free" > done And see how many of the AGs below 1TB (~6.4GB per AG, so those below about about AG 160) have no free space. To allocate new inodes you need a contiguous extent of 16k plus another 4 free blocks, so you need at _least_ 8 free blocks in an AG to allocate a new inode chunk on disk. If this is the case, then you need to delete some files to get space free below 1TB for more inodes and then copy a large file or two so they are moved above the 1TB mark, then remove the original copy to make space for inodes below 1TB. Or get a 64bit machine and use inode64. ;) HTH. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sat Feb 3 15:43:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 03 Feb 2007 15:43:36 -0800 (PST) X-Spam-oss-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l13NhNqw030805 for ; Sat, 3 Feb 2007 15:43:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA29133; Sun, 4 Feb 2007 10:42:23 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l13NgM7Y113492087; Sun, 4 Feb 2007 10:42:23 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l13NgLZt113244723; Sun, 4 Feb 2007 10:42:21 +1100 (AEDT) Date: Sun, 4 Feb 2007 10:42:21 +1100 From: David Chinner To: KE Liew Cc: xfs@oss.sgi.com Subject: Re: bad magic and dubious inode Message-ID: <20070203234221.GE44411608@melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 10549 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1205 Lines: 44 On Sat, Feb 03, 2007 at 06:59:29PM +0100, KE Liew wrote: > Hello, > > It's been a great day, and this is the situation. Files were being > transfered from one hdd to another, SATA to IDE, and BANG and error > occured, can't remember exactly what, but I had to umount it. Can you look in your syslog for the forced shutdown messages? > Successful, and ran xfs_check > > ==================== > eXiStEnCe:~# xfs_check -s /dev/hdb > bad magic # 0 in inobt block 15/916145 > ==================== > > Doesn't look good at all. I attempted the famous xfs_repair :) You ran "xfs_repair -n" which means it didn't fix anything; it just told you about errors it found. > No modify flag set, skipping phase 5 > Inode allocation btrees are too corrupted, skipping phases 6 and 7 > No modify flag set, skipping filesystem flush and exiting. > ==================== > > As you can see, it's almost dead? No, it's not dead - xfs-repair should be able to fix the problem if you let it. > I haven't mount it yet, so I hope > it's all safe and cool. What should be the next step for me to take? run xfs_repair without the -n flag. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Feb 4 05:26:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 04 Feb 2007 05:26:05 -0800 (PST) X-Spam-oss-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_50,RCVD_IN_PBL, SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r497472 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l14DPwqw032356 for ; Sun, 4 Feb 2007 05:26:01 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id 5B97D1A000697; Sun, 4 Feb 2007 08:25:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 49483A050A86 for ; Sun, 4 Feb 2007 08:25:04 -0500 (EST) Date: Sun, 4 Feb 2007 08:25:04 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com Subject: Spam on list? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 10554 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 250 Lines: 9 Who runs the XFS mailing list admin-wise? Could we add some basic anti-spam measures, I am not subscribed to many mailing lists but this one seems to generate the most spam. Any chance they'd consider switching from Sendmail -> Postfix? Justin. From owner-xfs@oss.sgi.com Sun Feb 4 10:45:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 04 Feb 2007 10:45:12 -0800 (PST) X-Spam-oss-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l14Ij6qw013555 for ; Sun, 4 Feb 2007 10:45:07 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E180018013A80; Sun, 4 Feb 2007 12:44:11 -0600 (CST) Message-ID: <45C62982.1090206@sandeen.net> Date: Sun, 04 Feb 2007 12:44:18 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Justin Piszcz CC: xfs@oss.sgi.com Subject: Re: Spam on list? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10555 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 579 Lines: 24 Justin Piszcz wrote: > Who runs the XFS mailing list admin-wise? A cabal... > Could we add some basic anti-spam measures, I am not subscribed to many > mailing lists but this one seems to generate the most spam. > > Any chance they'd consider switching from Sendmail -> Postfix? > > Justin. > > There are actually many spam measures in place... spamassassin, and others, but it seems they just can't keep up. The one spam measure that's not in place is subscriber-only posting. I think it may be time to revisit that decision. It's gotten really bad lately. -Eric From owner-xfs@oss.sgi.com Sun Feb 4 11:42:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 04 Feb 2007 11:42:39 -0800 (PST) X-Spam-oss-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l14JgW3c020847 for ; Sun, 4 Feb 2007 11:42:33 -0800 Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by postfix1-g20.free.fr (Postfix) with ESMTP id 08B288FE0E5 for ; Sun, 4 Feb 2007 20:18:11 +0100 (CET) Received: from galadriel.home (pla78-1-82-235-234-79.fbx.proxad.net [82.235.234.79]) by smtp2-g19.free.fr (Postfix) with ESMTP id C7DFC812E; Sun, 4 Feb 2007 20:18:08 +0100 (CET) Date: Sun, 4 Feb 2007 20:18:08 +0100 From: Emmanuel Florac To: Eric Sandeen Cc: Justin Piszcz , xfs@oss.sgi.com Subject: Re: Spam on list? Message-ID: <20070204201808.05240120@galadriel.home> In-Reply-To: <45C62982.1090206@sandeen.net> References: <45C62982.1090206@sandeen.net> Organization: Intellique X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l14JgY3c020851 X-archive-position: 10556 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: eflorac@intellique.com Precedence: bulk X-list: xfs Content-Length: 430 Lines: 14 Le Sun, 04 Feb 2007 12:44:18 -0600 vous écriviez: > The one spam measure that's not in place is subscriber-only posting. > > I think it may be time to revisit that decision. It's gotten really > bad lately. All other lists I'm following do so, and nobody complains. -- -------------------------------------------------- Emmanuel Florac www.intellique.com -------------------------------------------------- From owner-xfs@oss.sgi.com Sun Feb 4 13:47:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 04 Feb 2007 13:47:22 -0800 (PST) X-Spam-oss-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_05, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l14LlG3c009130 for ; Sun, 4 Feb 2007 13:47:17 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 0AB0918013A89; Sun, 4 Feb 2007 15:46:22 -0600 (CST) Message-ID: <45C6542D.6060803@sandeen.net> Date: Sun, 04 Feb 2007 15:46:21 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Eric Sandeen CC: Justin Piszcz , xfs@oss.sgi.com Subject: Re: Spam on list? References: <45C62982.1090206@sandeen.net> In-Reply-To: <45C62982.1090206@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10557 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 302 Lines: 10 Eric Sandeen wrote: > There are actually many spam measures in place... spamassassin, and > others, but it seems they just can't keep up. In the meantime we added another measure today, we'll see if it helps. I know it's bad... Thanks, -Eric (not the admin per se but at least the admin-pesterer) From owner-xfs@oss.sgi.com Sun Feb 4 13:57:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 04 Feb 2007 13:57:31 -0800 (PST) X-Spam-oss-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l14LvO3c011236 for ; Sun, 4 Feb 2007 13:57:26 -0800 Received: from edge (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id CF916AAC421; Mon, 5 Feb 2007 08:42:04 +1100 (EST) Subject: Re: Review: freezing sometimes leaves the log dirty From: Nathan Scott Reply-To: nscott@aconex.com To: Christoph Hellwig Cc: David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com In-Reply-To: <20070202114623.GA23187@infradead.org> References: <20070130220326.GM33919298@melbourne.sgi.com> <20070202114623.GA23187@infradead.org> Content-Type: text/plain Organization: Aconex Date: Mon, 05 Feb 2007 08:56:55 +1100 Message-Id: <1170626215.18017.394.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 10558 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 519 Lines: 19 On Fri, 2007-02-02 at 11:46 +0000, Christoph Hellwig wrote: > On Wed, Jan 31, 2007 at 09:03:26AM +1100, David Chinner wrote: > > + /* flush inodes and push all remaining buffers out to disk */ > > + xfs_quiesce_fs(mp); > > + > > + BUG_ON(atomic_read(&mp->m_active_trans) > 0); > > + > > xfs_vfsops.c is considered common code, so you should probably use > ASSERT here, not BUG_ON. There's also an ASSERT_ALWAYS macro IIRC, if you want the equivalent functionality of BUG_ON (i.e. always check). cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Feb 4 15:46:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 04 Feb 2007 15:46:26 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l14NkI3c024088 for ; Sun, 4 Feb 2007 15:46:20 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA27325; Mon, 5 Feb 2007 10:45:19 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l14NjH7Y114469623; Mon, 5 Feb 2007 10:45:18 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l14NjF53114324456; Mon, 5 Feb 2007 10:45:15 +1100 (AEDT) Date: Mon, 5 Feb 2007 10:45:15 +1100 From: David Chinner To: Nathan Scott Cc: Christoph Hellwig , David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: freezing sometimes leaves the log dirty Message-ID: <20070204234515.GI44411608@melbourne.sgi.com> References: <20070130220326.GM33919298@melbourne.sgi.com> <20070202114623.GA23187@infradead.org> <1170626215.18017.394.camel@edge> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1170626215.18017.394.camel@edge> User-Agent: Mutt/1.4.2.1i X-archive-position: 10559 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 716 Lines: 25 On Mon, Feb 05, 2007 at 08:56:55AM +1100, Nathan Scott wrote: > On Fri, 2007-02-02 at 11:46 +0000, Christoph Hellwig wrote: > > On Wed, Jan 31, 2007 at 09:03:26AM +1100, David Chinner wrote: > > > + /* flush inodes and push all remaining buffers out to disk */ > > > + xfs_quiesce_fs(mp); > > > + > > > + BUG_ON(atomic_read(&mp->m_active_trans) > 0); > > > + > > > > xfs_vfsops.c is considered common code, so you should probably use > > ASSERT here, not BUG_ON. > > There's also an ASSERT_ALWAYS macro IIRC, if you want the equivalent > functionality of BUG_ON (i.e. always check). True, I forgot about that one. Thx, Nathan.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Feb 5 01:33:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 01:33:08 -0800 (PST) X-Spam-oss-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.2.0-pre1-r497472 Received: from mx1.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l159Wx3c030924 for ; Mon, 5 Feb 2007 01:33:00 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 092561226B; Mon, 5 Feb 2007 10:32:04 +0100 (CET) To: Eric Sandeen Cc: Justin Piszcz , xfs@oss.sgi.com Subject: Re: Spam on list? References: <45C62982.1090206@sandeen.net> From: Andi Kleen Date: 05 Feb 2007 11:32:25 +0100 In-Reply-To: <45C62982.1090206@sandeen.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 10560 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: xfs Content-Length: 244 Lines: 9 Eric Sandeen writes: > > I think it may be time to revisit that decision. It's gotten really > bad lately. Please don't do that. It means nothing can be cross posted from l-k anymore, which would be pretty bad. -Andi From owner-xfs@oss.sgi.com Mon Feb 5 04:07:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 04:07:57 -0800 (PST) X-Spam-oss-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_20, MIME_8BIT_HEADER autolearn=no version=3.2.0-pre1-r497472 Received: from mx1.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l15C7o3c023322 for ; Mon, 5 Feb 2007 04:07:52 -0800 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 1F5A612368; Mon, 5 Feb 2007 13:06:52 +0100 (CET) From: Andi Kleen To: "Martin =?iso-8859-1?q?Schr=F6der?=" Subject: Re: Spam on list? Date: Mon, 5 Feb 2007 13:06:30 +0100 User-Agent: KMail/1.9.5 Cc: "Eric Sandeen" , "Justin Piszcz" , xfs@oss.sgi.com References: <68c491a60702050352t278e8381l72795ed9ea880029@mail.gmail.com> In-Reply-To: <68c491a60702050352t278e8381l72795ed9ea880029@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200702051306.34279.ak@suse.de> X-archive-position: 10564 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: xfs Content-Length: 565 Lines: 17 On Monday 05 February 2007 12:52, Martin Schröder wrote: > 05 Feb 2007 11:32:25 +0100, Andi Kleen : > > Please don't do that. It means nothing can be cross posted > > from l-k anymore, which would be pretty bad. > > Then set up a list admin who can approve such postings. That adds unacceptable latency. Also lists who spam senders with bounce messages tend to be dropped quickly from cc lists. Also you couldn't list xfs@ as bug report address anymore because bug report addresses must be available to everyone. In general it's a bad idea. -Andi From owner-xfs@oss.sgi.com Mon Feb 5 04:55:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 04:55:33 -0800 (PST) X-Spam-oss-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, MIME_8BIT_HEADER autolearn=no version=3.2.0-pre1-r497472 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l15CtQ3c003394 for ; Mon, 5 Feb 2007 04:55:28 -0800 Received: by wx-out-0506.google.com with SMTP id t4so1494055wxc for ; Mon, 05 Feb 2007 04:54:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YR+qKonBF/aS2E56+at/QWJXAJHly2ILVW9tt23ScPA2zwj0FOSyb6nYy8Ha3DRMqyBlon8YPGnQaeHYD356+oRMO2KFAc+bKe4dnwBd6HRXGMqDcCLR0WLqcXWJP4evnniUhm7mFbJ3tBsupGzUYCu7hZwFKLofwDIA9rfwVyM= Received: by 10.90.73.3 with SMTP id v3mr8530307aga.1170676352546; Mon, 05 Feb 2007 03:52:32 -0800 (PST) Received: by 10.90.95.5 with HTTP; Mon, 5 Feb 2007 03:52:32 -0800 (PST) Message-ID: <68c491a60702050352t278e8381l72795ed9ea880029@mail.gmail.com> Date: Mon, 5 Feb 2007 12:52:32 +0100 From: "=?ISO-8859-1?Q?Martin_Schr=F6der?=" To: "Andi Kleen" Subject: Re: Spam on list? Cc: "Eric Sandeen" , "Justin Piszcz" , xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45C62982.1090206@sandeen.net> X-Google-Sender-Auth: a247d31bfb9666e0 X-archive-position: 10565 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: martin@oneiros.de Precedence: bulk X-list: xfs Content-Length: 235 Lines: 9 05 Feb 2007 11:32:25 +0100, Andi Kleen : > Please don't do that. It means nothing can be cross posted > from l-k anymore, which would be pretty bad. Then set up a list admin who can approve such postings. Best Martin From owner-xfs@oss.sgi.com Mon Feb 5 06:19:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 06:19:39 -0800 (PST) X-Spam-oss-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_40, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l15EJU3c017256 for ; Mon, 5 Feb 2007 06:19:31 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 5E69C18013A89; Mon, 5 Feb 2007 08:18:35 -0600 (CST) Message-ID: <45C73CB9.5000402@sandeen.net> Date: Mon, 05 Feb 2007 08:18:33 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Andi Kleen CC: =?ISO-8859-1?Q?Martin_Schr=F6der?= , Justin Piszcz , xfs@oss.sgi.com Subject: Re: Spam on list? References: <68c491a60702050352t278e8381l72795ed9ea880029@mail.gmail.com> <200702051306.34279.ak@suse.de> In-Reply-To: <200702051306.34279.ak@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 10566 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 841 Lines: 26 Andi Kleen wrote: > On Monday 05 February 2007 12:52, Martin Schröder wrote: >> 05 Feb 2007 11:32:25 +0100, Andi Kleen : >>> Please don't do that. It means nothing can be cross posted >>> from l-k anymore, which would be pretty bad. >> Then set up a list admin who can approve such postings. > > That adds unacceptable latency. Also lists who spam senders > with bounce messages tend to be dropped quickly from cc lists. > > Also you couldn't list xfs@ as bug report address anymore because > bug report addresses must be available to everyone. > > In general it's a bad idea. > > -Andi > Well, I agree w/ those arguments too, Andi. I honestly don't know why oss seems to have so much more spam than, say, LKML. It is getting to a really bad level, and I sympathize with those whose inboxes are bombarded, too. -Eric From owner-xfs@oss.sgi.com Mon Feb 5 06:44:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 06:44:16 -0800 (PST) X-Spam-oss-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l15EiB3c021399 for ; Mon, 5 Feb 2007 06:44:12 -0800 Received: from lab41.emea.sgi.com (lab41.emea.sgi.com [144.253.75.41]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id l15EhGDW024352 for ; Mon, 5 Feb 2007 08:43:17 -0600 Received: by lab41.emea.sgi.com (Postfix, from userid 1000) id 3E9325801C; Mon, 5 Feb 2007 15:00:38 +0000 (GMT) To: xfs@oss.sgi.com Subject: TAKE 960791 - Fix assertion in xfs_attr_shortform_remove() Message-Id: <20070205150038.3E9325801C@lab41.emea.sgi.com> Date: Mon, 5 Feb 2007 15:00:38 +0000 (GMT) From: lachlan@lab41.emea.sgi.com (Lachlan McIlroy) X-archive-position: 10569 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@lab41.emea.sgi.com Precedence: bulk X-list: xfs Content-Length: 543 Lines: 18 Fix assertion in xfs_attr_shortform_remove(). Date: Tue Feb 6 01:40:20 AEDT 2007 Workarea: vpn-emea-sw-emea-160-32.emea.sgi.com:/home/lachlan/isms/2.6.x-null Inspected by: bnaujok Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28021a fs/xfs/xfs_attr_leaf.c - 1.106 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.106&r2=text&tr2=1.105&f=h - Fix assertion in xfs_attr_shortform_remove(). From owner-xfs@oss.sgi.com Mon Feb 5 10:00:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 10:00:32 -0800 (PST) X-Spam-oss-Status: No, score=0.0 required=5.0 tests=BAYES_50,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l15I0I3c025060 for ; Mon, 5 Feb 2007 10:00:21 -0800 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HE88I-0007a3-4J for linux-xfs@oss.sgi.com; Mon, 05 Feb 2007 19:00:02 +0100 Received: from c-134-232-3.f.dsl.de.ignite.net ([62.134.232.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Feb 2007 19:00:02 +0100 Received: from bernd-schubert by c-134-232-3.f.dsl.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Feb 2007 19:00:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Bernd Schubert Subject: Re: XFS "no space left" problem Date: Mon, 05 Feb 2007 18:58:04 +0100 Message-ID: References: <20070203183723.GA1652@dunno.espix.org> <20070203233828.GD44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-232-3.f.dsl.de.ignite.net User-Agent: KNode/0.10.4 X-archive-position: 10571 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bernd-schubert@gmx.de Precedence: bulk X-list: xfs Content-Length: 716 Lines: 18 David Chinner wrote: > Or get a 64bit machine and use inode64. ;) David, can you tell more in detail what you mean with "use inode64"? We also just migrated our server to xfs, the largest partition has a size of 4TB. Lets say in the future a problem occurs and we could solve this by a 64-bit system? Migrating to 64-bit wouldn't be difficult, since the server systems are already opterons. Only since we never bothered to migrate the installation to x86_64 its not 64-bit yet. Would we need to tell xfs somehow that it update its internal values to 64-bit integers or will it do that automatically? Btw, if you need 64-bit integers, why don't you use long long, or even better with C99 int64_t? Thanks, Bernd From owner-xfs@oss.sgi.com Mon Feb 5 14:08:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 14:08:47 -0800 (PST) X-Spam-oss-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l15M8e3c009160 for ; Mon, 5 Feb 2007 14:08:42 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HEB5N-0001bl-Sq; Mon, 05 Feb 2007 21:09:13 +0000 Date: Mon, 5 Feb 2007 21:09:13 +0000 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: freezing sometimes leaves the log dirty Message-ID: <20070205210913.GA6062@infradead.org> References: <20070130220326.GM33919298@melbourne.sgi.com> <20070202114623.GA23187@infradead.org> <20070202140706.GX33919298@melbourne.sgi.com> <20070205210245.GP44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070205210245.GP44411608@melbourne.sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10577 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 267 Lines: 9 On Tue, Feb 06, 2007 at 08:02:45AM +1100, David Chinner wrote: > On Sat, Feb 03, 2007 at 01:07:06AM +1100, David Chinner wrote: > > Patch below cleans all this up and also fixes the 2.4 tree as well. > > Can I get an ack from someone on this? > Looks good to me. From owner-xfs@oss.sgi.com Mon Feb 5 14:38:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 14:38:53 -0800 (PST) X-Spam-oss-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from pne-smtpout3-sn1.fre.skanova.net (pne-smtpout3-sn1.fre.skanova.net [81.228.11.120]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l15Mcf3c014086 for ; Mon, 5 Feb 2007 14:38:45 -0800 Received: from safari.iki.fi (80.223.106.128) by pne-smtpout3-sn1.fre.skanova.net (7.2.075) id 45AE1FD5001033AC for xfs@oss.sgi.com; Mon, 5 Feb 2007 22:29:06 +0100 Received: (qmail 9810 invoked by uid 500); 5 Feb 2007 21:29:06 -0000 Date: Mon, 5 Feb 2007 23:29:06 +0200 From: Sami Farin To: xfs@oss.sgi.com Subject: Re: Spam on list? Message-ID: <20070205212906.GA6096@m.safari.iki.fi> Mail-Followup-To: Sami Farin , xfs@oss.sgi.com References: <68c491a60702050352t278e8381l72795ed9ea880029@mail.gmail.com> <200702051306.34279.ak@suse.de> <45C73CB9.5000402@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45C73CB9.5000402@sandeen.net> User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 10579 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: safari-xfs@safari.iki.fi Precedence: bulk X-list: xfs Content-Length: 2166 Lines: 51 On Mon, Feb 05, 2007 at 08:18:33 -0600, Eric Sandeen wrote: > Andi Kleen wrote: > >On Monday 05 February 2007 12:52, Martin Schröder wrote: > >>05 Feb 2007 11:32:25 +0100, Andi Kleen : > >>>Please don't do that. It means nothing can be cross posted > >>>from l-k anymore, which would be pretty bad. > >>Then set up a list admin who can approve such postings. > > > >That adds unacceptable latency. Also lists who spam senders > >with bounce messages tend to be dropped quickly from cc lists. > > > >Also you couldn't list xfs@ as bug report address anymore because > >bug report addresses must be available to everyone. > > > >In general it's a bad idea. > > > >-Andi > > > > Well, I agree w/ those arguments too, Andi. > > I honestly don't know why oss seems to have so much more spam than, say, > LKML. It is getting to a really bad level, and I sympathize with those > whose inboxes are bombarded, too. Those 419 scams and phishes are caught by for example a bayesian filter. That's what I have done since 2003. As for the "only subscribers can post" as an anti-spam measure, I can say that for those mailing lists where they are doing it, the emails from non-subscribers go to /dev/null and if you contact owner, it goes, too, because you are not subscribed (!!) OR they just tell you to screw off. After waiting for a week. If they feel like it. This is not to say that xfs ml would be doing this /dev/nulling , this is just my general feeling about this anti-spam measure and its usability. Besides, I use different (secret) subscription email address for mailing lists than in the From header field when I write to the list. This way it's easy to have different anti-spam measures for subscription email (e.g., none) than for the email in From (e.g., I can reject out-of-office notices and other brokeness). If I had to use the same email for both purposes, I couldn't for example reject based on 419 scammers' IP addresses found in Received etc. header fields because then I would get auto-unsubscribed from this mailing list when ecartis thinks my email is broken. -- Do what you love because life is too short for anything else. From owner-xfs@oss.sgi.com Mon Feb 5 15:47:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 15:48:03 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l15Nlt3c026057 for ; Mon, 5 Feb 2007 15:47:56 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A960118013A80; Mon, 5 Feb 2007 17:47:54 -0600 (CST) Message-ID: <45C7C228.2090609@sandeen.net> Date: Mon, 05 Feb 2007 17:47:52 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: nscott@aconex.com CC: Andi Kleen , =?UTF-8?B?TWFydGluIFNjaHLDtmRlcg==?= , Justin Piszcz , xfs@oss.sgi.com Subject: Re: Spam on list? References: <68c491a60702050352t278e8381l72795ed9ea880029@mail.gmail.com> <200702051306.34279.ak@suse.de> <45C73CB9.5000402@sandeen.net> <1170712730.18017.452.camel@edge> In-Reply-To: <1170712730.18017.452.camel@edge> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 10580 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 794 Lines: 22 Nathan Scott wrote: > On Mon, 2007-02-05 at 08:18 -0600, Eric Sandeen wrote: >> Andi Kleen wrote: >>> On Monday 05 February 2007 12:52, Martin Schröder wrote: >>>> 05 Feb 2007 11:32:25 +0100, Andi Kleen : >>>>> Please don't do that. It means nothing can be cross posted >>>>> from l-k anymore, which would be pretty bad. >>>> Then set up a list admin who can approve such postings. >>> That adds unacceptable latency. Also lists who spam senders >>> with bounce messages tend to be dropped quickly from cc lists. >>> >>> Also you couldn't list xfs@ as bug report address anymore because >>> bug report addresses must be available to everyone. >>> >>> In general it's a bad idea. > > *nod*, it really cannot become a closed list. Ok ok everyone, it was just a thought ;-) -Eric From owner-xfs@oss.sgi.com Mon Feb 5 17:25:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 17:25:49 -0800 (PST) X-Spam-oss-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_05, DATE_IN_PAST_12_24,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r497472 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l161Pd3c012032 for ; Mon, 5 Feb 2007 17:25:41 -0800 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HEF51-00012E-9n for linux-xfs@oss.sgi.com; Tue, 06 Feb 2007 02:25:07 +0100 Received: from ppp79-69.lns1.mel3.internode.on.net ([59.167.79.69]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 02:25:02 +0100 Received: from jasonjgw by ppp79-69.lns1.mel3.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 02:25:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Jason White Subject: Re: Spam on list? Date: Mon, 5 Feb 2007 09:59:14 +0000 (UTC) Message-ID: References: <45C62982.1090206@sandeen.net> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ppp79-69.lns1.mel3.internode.on.net User-Agent: slrn/0.9.8.1pl1 (Debian) X-archive-position: 10582 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jasonjgw@internode.on.net Precedence: bulk X-list: xfs Content-Length: 681 Lines: 19 On 2007-02-05, Andi Kleen wrote: > Eric Sandeen writes: >> >> I think it may be time to revisit that decision. It's gotten really >> bad lately. I agree. > > Please don't do that. It means nothing can be cross posted > from l-k anymore, which would be pretty bad. Posting from Gmane (nntp://news.gmane.org/) is also desirable, and (relatively) safe as it implements a challenge/response procedure and has other anti-spam controls. Is it possible to configure the list server to be more selective about who can post (i.e., detecting header contents that include known good lists, Gmane postings, etc.)? There's always "greylisting", too. From owner-xfs@oss.sgi.com Mon Feb 5 22:47:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 22:47:18 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l166l63c021473 for ; Mon, 5 Feb 2007 22:47:08 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13875; Tue, 6 Feb 2007 17:47:02 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 4E7B358FF657; Tue, 6 Feb 2007 17:47:02 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 960192 - XFS sysctl cleanup Message-Id: <20070206064702.4E7B358FF657@chook.melbourne.sgi.com> Date: Tue, 6 Feb 2007 17:47:02 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10583 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 776 Lines: 22 XFS sysctl cleanups Removes unneeded sysctl insert at head behaviour. Cleans up sysctl definitions to use C99 initialisers. Patch provided by Eric W. Biederman. Signed-off-by: Eric W. Biederman Date: Tue Feb 6 17:46:02 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: dgc,ebiederm@xmission.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28031a fs/xfs/linux-2.6/xfs_sysctl.c - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.c.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h - sysctl cleanup patch provided by Eric W. Biederman. Signed-off-by: Eric W. Biederman From owner-xfs@oss.sgi.com Mon Feb 5 23:20:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Feb 2007 23:20:49 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l167Kg3c027848 for ; Mon, 5 Feb 2007 23:20:44 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA14634; Tue, 6 Feb 2007 18:20:37 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 1ECC458FF657; Tue, 6 Feb 2007 18:20:37 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 960868 - Clean up use of vfs attr flags Message-Id: <20070206072037.1ECC458FF657@chook.melbourne.sgi.com> Date: Tue, 6 Feb 2007 18:20:37 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10585 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 788 Lines: 23 Clean up use of VFS attr flags Use the the generic VFS attr flags where appropriate instead of open coding them to the same values. Patch provided by Eric Sandeen. Signed-off-by: Eric Sandeen Date: Tue Feb 6 18:19:58 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: dgc,sandeen@sandeen.net,hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28033a fs/xfs/linux-2.6/xfs_ioctl.c - 1.143 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.143&r2=text&tr2=1.142&f=h - Use generic VFS attr flags rather than open coding them. Signed-off-by: Eric Sandeen From owner-xfs@oss.sgi.com Tue Feb 6 00:09:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Feb 2007 00:09:22 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1689F3c002603 for ; Tue, 6 Feb 2007 00:09:17 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA15701; Tue, 6 Feb 2007 19:09:10 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 678B058FF657; Tue, 6 Feb 2007 19:09:10 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 960196 - remove unused "firstblock" arg from xfs_bmap_finish() Message-Id: <20070206080910.678B058FF657@chook.melbourne.sgi.com> Date: Tue, 6 Feb 2007 19:09:10 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10586 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2816 Lines: 63 Remove unused argument to xfs_bmap_finish The firstblock argument to xfs_bmap_finish is not used by that function. Remove it and cleanup the code a bit. Patch provided by Eric Sandeen. Signed-off-by: Eric Sandeen Date: Tue Feb 6 18:59:03 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: dgc,sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28034a fs/xfs/xfs_vnodeops.c - 1.688 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.688&r2=text&tr2=1.687&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen fs/xfs/xfs_rtalloc.c - 1.104 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.104&r2=text&tr2=1.103&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen fs/xfs/xfs_inode.c - 1.459 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.459&r2=text&tr2=1.458&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen fs/xfs/xfs_bmap.h - 1.98 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.98&r2=text&tr2=1.97&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen fs/xfs/xfs_bmap.c - 1.362 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.362&r2=text&tr2=1.361&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen fs/xfs/xfs_rename.c - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen fs/xfs/xfs_attr.c - 1.142 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.142&r2=text&tr2=1.141&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen fs/xfs/quota/xfs_dquot.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen fs/xfs/xfs_iomap.c - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h - Remove unused firstblock argument from xfs_bmap_finish. Signed-off-by: Eric Sandeen From owner-xfs@oss.sgi.com Tue Feb 6 15:56:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Feb 2007 15:56:52 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l16Nui3c009855 for ; Tue, 6 Feb 2007 15:56:46 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10568; Wed, 7 Feb 2007 10:56:38 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 4300558C4C27; Wed, 7 Feb 2007 10:56:38 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 959267 - bad clientid during log replay of snapshot image Message-Id: <20070206235638.4300558C4C27@chook.melbourne.sgi.com> Date: Wed, 7 Feb 2007 10:56:38 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10589 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1619 Lines: 38 Make freeze code a little cleaner. Fixes a few small issues (mostly cosmetic) that were picked up during the review cycle for the last set of freeze path changes. Date: Wed Feb 7 10:56:10 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28035a fs/xfs/xfs_vfsops.c - 1.515 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.515&r2=text&tr2=1.514&f=h - Convert SYNC_DIO_WAIT to SYNC_IOWAIT as it really waits for all I/O, not just direct I/O. fs/xfs/linux-2.6/xfs_vfs.h - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h - Convert SYNC_DIO_WAIT to SYNC_IOWAIT as it really waits for all I/O, not just direct I/O. fs/xfs/linux-2.6/xfs_super.c - 1.378 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.378&r2=text&tr2=1.377&f=h - Convert SYNC_DIO_WAIT to SYNC_IOWAIT as it really waits for all I/O, not just direct I/O. fs/xfs/linux-2.4/xfs_vfs.h - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.h.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h - add/remove SYNC_* flags for freeze path changes. fs/xfs/linux-2.4/xfs_super.c - 1.334 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.334&r2=text&tr2=1.333&f=h - Use new flush ordering and semantics in the freeze path. From owner-xfs@oss.sgi.com Tue Feb 6 16:35:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Feb 2007 16:35:49 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l170Zg3c018388 for ; Tue, 6 Feb 2007 16:35:44 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12077; Wed, 7 Feb 2007 11:35:37 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 1F36858C4C27; Wed, 7 Feb 2007 11:35:37 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 960897 - Remove a bunch of unused functions from XFS Message-Id: <20070207003537.1F36858C4C27@chook.melbourne.sgi.com> Date: Wed, 7 Feb 2007 11:35:37 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10591 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2468 Lines: 61 Remove a bunch of unused functions from XFS. Patch provided by Eric Sandeen (sandeen@sandeen.net). Signed-off-by: Eric Sandeen Date: Wed Feb 7 11:35:11 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: dgc,sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28038a fs/xfs/xfs_da_btree.c - 1.174 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.174&r2=text&tr2=1.173&f=h - Remove unused functions. Signed-off-by: Eric Sandeen fs/xfs/xfs_da_btree.h - 1.66 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.h.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h - Remove unused functions. Signed-off-by: Eric Sandeen fs/xfs/xfs_rtalloc.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h - Remove unused functions. Signed-off-by: Eric Sandeen fs/xfs/xfs_rtalloc.c - 1.105 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h - Remove unused functions. Signed-off-by: Eric Sandeen fs/xfs/xfs_bmap_btree.h - 1.76 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h - Remove unused functions. Signed-off-by: Eric Sandeen fs/xfs/xfs_bmap_btree.c - 1.160 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.160&r2=text&tr2=1.159&f=h - Remove unused functions. Signed-off-by: Eric Sandeen fs/xfs/xfs_error.c - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h - Remove unused functions. Signed-off-by: Eric Sandeen fs/xfs/xfs_error.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h - Remove unused functions. Signed-off-by: Eric Sandeen fs/xfs/xfs_bmap.c - 1.364 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.364&r2=text&tr2=1.363&f=h - Remove unused functions. Signed-off-by: Eric Sandeen From owner-xfs@oss.sgi.com Tue Feb 6 17:19:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Feb 2007 17:19:35 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l171JR3c023704 for ; Tue, 6 Feb 2007 17:19:29 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id l170RSDW021405 for ; Tue, 6 Feb 2007 18:27:29 -0600 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11709; Wed, 7 Feb 2007 11:27:21 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id D9D8F58C4C27; Wed, 7 Feb 2007 11:27:21 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 960197 - remove unused arguments from the XFS_BTREE_*_ADDR functions Message-Id: <20070207002721.D9D8F58C4C27@chook.melbourne.sgi.com> Date: Wed, 7 Feb 2007 11:27:21 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10592 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2950 Lines: 63 Remove unused arguments from the XFS_BTREE_*_ADDR macros. It makes it incrementally clearer to read the code when the top of a macro spaghetti-pile only receives the 3 arguments it uses, rather than 2 extra ones which are not used. Also when you start pulling this thread out of the sweater (i.e. remove unused args from XFS_BTREE_*_ADDR), a couple other third arms etc fall off too. If they're not used in the macro, then they sometimes don't need to be passed to the function calling the macro either, etc.... Patch provided by Eric Sandeen (sandeen@sandeen.net). Signed-off-by: Eric Sandeen Date: Wed Feb 7 11:26:40 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: dgc,sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:28037a fs/xfs/xfsidbg.c - 1.311 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.311&r2=text&tr2=1.310&f=h - Remove unused arguments from XFS_BTREE_*_ADDR macros. Signed-off-by: Eric Sandeen fs/xfs/xfs_ialloc_btree.h - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.h.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h - Remove unused arguments from XFS_BTREE_*_ADDR macros. Signed-off-by: Eric Sandeen fs/xfs/xfs_bmap_btree.h - 1.75 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.h.diff?r1=text&tr1=1.75&r2=text&tr2=1.74&f=h - Remove unused arguments from XFS_BTREE_*_ADDR macros. Signed-off-by: Eric Sandeen fs/xfs/xfs_bmap_btree.c - 1.159 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.159&r2=text&tr2=1.158&f=h - Remove unused arguments from XFS_BTREE_*_ADDR macros. Signed-off-by: Eric Sandeen fs/xfs/xfs_btree.h - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.h.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h - Remove unused arguments from XFS_BTREE_*_ADDR macros. Signed-off-by: Eric Sandeen fs/xfs/xfs_fsops.c - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h - Remove unused arguments from XFS_BTREE_*_ADDR macros. Signed-off-by: Eric Sandeen fs/xfs/xfs_bmap.c - 1.363 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.363&r2=text&tr2=1.362&f=h - Remove unused arguments from XFS_BTREE_*_ADDR macros. Signed-off-by: Eric Sandeen fs/xfs/xfs_alloc_btree.h - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.h.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h - Remove unused arguments from XFS_BTREE_*_ADDR macros. Signed-off-by: Eric Sandeen From owner-xfs@oss.sgi.com Tue Feb 6 20:55:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Feb 2007 20:55:26 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l174tF3c022565 for ; Tue, 6 Feb 2007 20:55:16 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4518518003EF5 for ; Tue, 6 Feb 2007 22:55:11 -0600 (CST) Message-ID: <45C95BAF.6080005@sandeen.net> Date: Tue, 06 Feb 2007 22:55:11 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] remove unused "lsn" argument of xfs_trans_commit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10594 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 19162 Lines: 627 The last argument "lsn" of xfs_trans_commit() is always called with NULL. dmapi/xfs_dm.c | 4 ++-- quota/xfs_dquot.c | 3 +-- quota/xfs_qm.c | 5 ++--- quota/xfs_qm_syscalls.c | 6 +++--- xfs_attr.c | 12 ++++-------- xfs_attr_leaf.c | 2 +- xfs_bmap.c | 4 ++-- xfs_dfrag.c | 2 +- xfs_fsops.c | 4 ++-- xfs_inode.c | 2 +- xfs_iomap.c | 7 +++---- xfs_log_recover.c | 4 ++-- xfs_mount.c | 2 +- xfs_qmops.c | 2 +- xfs_rename.c | 2 +- xfs_rtalloc.c | 6 +++--- xfs_rw.c | 4 ++-- xfs_trans.c | 6 ------ xfs_trans.h | 4 +--- xfs_utils.c | 5 ++--- xfs_vfsops.c | 2 +- xfs_vnodeops.c | 33 ++++++++++++++++----------------- 22 files changed, 52 insertions(+), 69 deletions(-) Signed-off-by: Eric Sandeen --- Index: linux/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux/fs/xfs.orig/dmapi/xfs_dm.c +++ linux/fs/xfs/dmapi/xfs_dm.c @@ -1168,7 +1168,7 @@ xfs_dm_f_set_eventlist( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); VN_HOLD(vp); - xfs_trans_commit(tp, 0, NULL); + xfs_trans_commit(tp, 0); return(0); } @@ -3021,7 +3021,7 @@ xfs_dm_set_region( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); VN_HOLD(vp); - xfs_trans_commit(tp, 0, NULL); + xfs_trans_commit(tp, 0); /* Return the proper value for *exactflagp depending upon whether or not we "changed" the user's managed region. In other words, if the user Index: linux/fs/xfs/quota/xfs_dquot.c =================================================================== --- linux/fs/xfs.orig/quota/xfs_dquot.c +++ linux/fs/xfs/quota/xfs_dquot.c @@ -753,8 +753,7 @@ xfs_qm_idtodq( goto error0; } if (tp) { - if ((error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, - NULL))) + if ((error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES))) goto error1; } Index: linux/fs/xfs/quota/xfs_qm.c =================================================================== --- linux/fs/xfs.orig/quota/xfs_qm.c +++ linux/fs/xfs/quota/xfs_qm.c @@ -1453,8 +1453,7 @@ xfs_qm_qino_alloc( XFS_SB_UNLOCK(mp, s); xfs_mod_sb(tp, sbfields); - if ((error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, - NULL))) { + if ((error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES))) { xfs_fs_cmn_err(CE_ALERT, mp, "XFS qino_alloc failed!"); return error; } @@ -2405,7 +2404,7 @@ xfs_qm_write_sb_changes( } xfs_mod_sb(tp, flags); - (void) xfs_trans_commit(tp, 0, NULL); + (void) xfs_trans_commit(tp, 0); return 0; } Index: linux/fs/xfs/quota/xfs_qm_syscalls.c =================================================================== --- linux/fs/xfs.orig/quota/xfs_qm_syscalls.c +++ linux/fs/xfs/quota/xfs_qm_syscalls.c @@ -735,7 +735,7 @@ xfs_qm_scall_setqlim( xfs_trans_log_dquot(tp, dqp); xfs_dqtrace_entry(dqp, "Q_SETQLIM: COMMIT"); - xfs_trans_commit(tp, 0, NULL); + xfs_trans_commit(tp, 0); xfs_qm_dqprint(dqp); xfs_qm_dqrele(dqp); mutex_unlock(&(XFS_QI_QOFFLOCK(mp))); @@ -809,7 +809,7 @@ xfs_qm_log_quotaoff_end( * We don't care about quotoff's performance. */ xfs_trans_set_sync(tp); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); return (error); } @@ -852,7 +852,7 @@ xfs_qm_log_quotaoff( * We don't care about quotoff's performance. */ xfs_trans_set_sync(tp); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); error0: if (error) { Index: linux/fs/xfs/xfs_attr.c =================================================================== --- linux/fs/xfs.orig/xfs_attr.c +++ linux/fs/xfs/xfs_attr.c @@ -328,8 +328,7 @@ xfs_attr_set_int(xfs_inode_t *dp, const xfs_trans_set_sync(args.trans); } err2 = xfs_trans_commit(args.trans, - XFS_TRANS_RELEASE_LOG_RES, - NULL); + XFS_TRANS_RELEASE_LOG_RES); xfs_iunlock(dp, XFS_ILOCK_EXCL); /* @@ -397,8 +396,7 @@ xfs_attr_set_int(xfs_inode_t *dp, const * Commit the last in the sequence of transactions. */ xfs_trans_log_inode(args.trans, dp, XFS_ILOG_CORE); - error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES, - NULL); + error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES); xfs_iunlock(dp, XFS_ILOCK_EXCL); /* @@ -544,8 +542,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, con * Commit the last in the sequence of transactions. */ xfs_trans_log_inode(args.trans, dp, XFS_ILOG_CORE); - error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES, - NULL); + error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES); xfs_iunlock(dp, XFS_ILOCK_EXCL); /* @@ -859,8 +856,7 @@ xfs_attr_inactive(xfs_inode_t *dp) * Commit the last in the sequence of transactions. */ xfs_trans_log_inode(trans, dp, XFS_ILOG_CORE); - error = xfs_trans_commit(trans, XFS_TRANS_RELEASE_LOG_RES, - NULL); + error = xfs_trans_commit(trans, XFS_TRANS_RELEASE_LOG_RES); xfs_iunlock(dp, XFS_ILOCK_EXCL); return(error); Index: linux/fs/xfs/xfs_attr_leaf.c =================================================================== --- linux/fs/xfs.orig/xfs_attr_leaf.c +++ linux/fs/xfs/xfs_attr_leaf.c @@ -3053,7 +3053,7 @@ xfs_attr_rolltrans(xfs_trans_t **transp, * is in progress. The caller takes the responsibility to cancel * the duplicate transaction that gets returned. */ - if ((error = xfs_trans_commit(trans, 0, NULL))) + if ((error = xfs_trans_commit(trans, 0))) return (error); trans = *transp; Index: linux/fs/xfs/xfs_bmap.c =================================================================== --- linux/fs/xfs.orig/xfs_bmap.c +++ linux/fs/xfs/xfs_bmap.c @@ -4071,7 +4071,7 @@ xfs_bmap_add_attrfork( } if ((error = xfs_bmap_finish(&tp, &flist, &committed))) goto error2; - error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); ASSERT(ip->i_df.if_ext_max == XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); return error; @@ -4227,7 +4227,7 @@ xfs_bmap_finish( logres = ntp->t_log_res; logcount = ntp->t_log_count; ntp = xfs_trans_dup(*tp); - error = xfs_trans_commit(*tp, 0, NULL); + error = xfs_trans_commit(*tp, 0); *tp = ntp; *committed = 1; /* Index: linux/fs/xfs/xfs_dfrag.c =================================================================== --- linux/fs/xfs.orig/xfs_dfrag.c +++ linux/fs/xfs/xfs_dfrag.c @@ -382,7 +382,7 @@ xfs_swap_extents( xfs_trans_set_sync(tp); } - error = xfs_trans_commit(tp, XFS_TRANS_SWAPEXT, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_SWAPEXT); locked = 0; error0: Index: linux/fs/xfs/xfs_fsops.c =================================================================== --- linux/fs/xfs.orig/xfs_fsops.c +++ linux/fs/xfs/xfs_fsops.c @@ -346,7 +346,7 @@ xfs_growfs_data_private( xfs_trans_mod_sb(tp, XFS_TRANS_SB_FDBLOCKS, nfree); if (dpct) xfs_trans_mod_sb(tp, XFS_TRANS_SB_IMAXPCT, dpct); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); if (error) { return error; } @@ -605,7 +605,7 @@ xfs_fs_log_dummy( xfs_trans_ihold(tp, ip); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); xfs_trans_set_sync(tp); - xfs_trans_commit(tp, 0, NULL); + xfs_trans_commit(tp, 0); xfs_iunlock(ip, XFS_ILOCK_EXCL); } Index: linux/fs/xfs/xfs_inode.c =================================================================== --- linux/fs/xfs.orig/xfs_inode.c +++ linux/fs/xfs/xfs_inode.c @@ -1746,7 +1746,7 @@ xfs_itruncate_finish( xfs_trans_log_inode(ntp, ip, XFS_ILOG_CORE); } ntp = xfs_trans_dup(ntp); - (void) xfs_trans_commit(*tp, 0, NULL); + (void) xfs_trans_commit(*tp, 0); *tp = ntp; error = xfs_trans_reserve(ntp, 0, XFS_ITRUNCATE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, Index: linux/fs/xfs/xfs_iomap.c =================================================================== --- linux/fs/xfs.orig/xfs_iomap.c +++ linux/fs/xfs/xfs_iomap.c @@ -543,7 +543,7 @@ xfs_iomap_write_direct( error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) goto error0; - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (error) goto error_out; @@ -840,8 +840,7 @@ xfs_iomap_write_allocate( if (error) goto trans_cancel; - error = xfs_trans_commit(tp, - XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (error) goto error0; @@ -948,7 +947,7 @@ xfs_iomap_write_unwritten( if (error) goto error_on_bmapi_transaction; - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); xfs_iunlock(ip, XFS_ILOCK_EXCL); if (error) return XFS_ERROR(error); Index: linux/fs/xfs/xfs_log_recover.c =================================================================== --- linux/fs/xfs.orig/xfs_log_recover.c +++ linux/fs/xfs/xfs_log_recover.c @@ -3016,7 +3016,7 @@ xlog_recover_process_efi( } efip->efi_flags |= XFS_EFI_RECOVERED; - xfs_trans_commit(tp, 0, NULL); + xfs_trans_commit(tp, 0); } /* @@ -3143,7 +3143,7 @@ xlog_recover_clear_agi_bucket( xfs_trans_log_buf(tp, agibp, offset, (offset + sizeof(xfs_agino_t) - 1)); - (void) xfs_trans_commit(tp, 0, NULL); + (void) xfs_trans_commit(tp, 0); } /* Index: linux/fs/xfs/xfs_mount.c =================================================================== --- linux/fs/xfs.orig/xfs_mount.c +++ linux/fs/xfs/xfs_mount.c @@ -1653,7 +1653,7 @@ xfs_mount_log_sbunit( return; } xfs_mod_sb(tp, fields); - xfs_trans_commit(tp, 0, NULL); + xfs_trans_commit(tp, 0); } Index: linux/fs/xfs/xfs_qmops.c =================================================================== --- linux/fs/xfs.orig/xfs_qmops.c +++ linux/fs/xfs/xfs_qmops.c @@ -78,7 +78,7 @@ xfs_mount_reset_sbqflags(xfs_mount_t *mp return error; } xfs_mod_sb(tp, XFS_SB_QFLAGS); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); return error; } Index: linux/fs/xfs/xfs_rename.c =================================================================== --- linux/fs/xfs.orig/xfs_rename.c +++ linux/fs/xfs/xfs_rename.c @@ -584,7 +584,7 @@ xfs_rename( * trans_commit will unlock src_ip, target_ip & decrement * the vnode references. */ - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (target_ip != NULL) { xfs_refcache_purge_ip(target_ip); IRELE(target_ip); Index: linux/fs/xfs/xfs_rtalloc.c =================================================================== --- linux/fs/xfs.orig/xfs_rtalloc.c +++ linux/fs/xfs/xfs_rtalloc.c @@ -150,7 +150,7 @@ xfs_growfs_rt_alloc( error = xfs_bmap_finish(&tp, &flist, &committed); if (error) goto error_exit; - xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); /* * Now we need to clear the allocated blocks. * Do this one block per transaction, to keep it simple. @@ -187,7 +187,7 @@ xfs_growfs_rt_alloc( /* * Commit the transaction. */ - xfs_trans_commit(tp, 0, NULL); + xfs_trans_commit(tp, 0); } /* * Go on to the next extent, if any. @@ -2042,7 +2042,7 @@ xfs_growfs_rt( /* * Commit the transaction. */ - xfs_trans_commit(tp, 0, NULL); + xfs_trans_commit(tp, 0); } if (error) Index: linux/fs/xfs/xfs_rw.c =================================================================== --- linux/fs/xfs.orig/xfs_rw.c +++ linux/fs/xfs/xfs_rw.c @@ -83,7 +83,7 @@ xfs_write_clear_setuid( } xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); xfs_trans_set_sync(tp); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); xfs_iunlock(ip, XFS_ILOCK_EXCL); return 0; } @@ -164,7 +164,7 @@ xfs_write_sync_logforce( xfs_trans_ihold(tp, ip); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); xfs_trans_set_sync(tp); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); xfs_iunlock(ip, XFS_ILOCK_EXCL); } } Index: linux/fs/xfs/xfs_trans.c =================================================================== --- linux/fs/xfs.orig/xfs_trans.c +++ linux/fs/xfs/xfs_trans.c @@ -753,7 +753,6 @@ int _xfs_trans_commit( xfs_trans_t *tp, uint flags, - xfs_lsn_t *commit_lsn_p, int *log_flushed) { xfs_log_iovec_t *log_vector; @@ -812,8 +811,6 @@ shut_us_down: xfs_trans_free_busy(tp); xfs_trans_free(tp); XFS_STATS_INC(xs_trans_empty); - if (commit_lsn_p) - *commit_lsn_p = commit_lsn; return (shutdown); } ASSERT(tp->t_ticket != NULL); @@ -864,9 +861,6 @@ shut_us_down: kmem_free(log_vector, nvec * sizeof(xfs_log_iovec_t)); } - if (commit_lsn_p) - *commit_lsn_p = commit_lsn; - /* * If we got a log write error. Unpin the logitems that we * had pinned, clean up, free trans structure, and return error. Index: linux/fs/xfs/xfs_trans.h =================================================================== --- linux/fs/xfs.orig/xfs_trans.h +++ linux/fs/xfs/xfs_trans.h @@ -988,10 +988,8 @@ void xfs_trans_log_efd_extent(xfs_trans xfs_extlen_t); int _xfs_trans_commit(xfs_trans_t *, uint flags, - xfs_lsn_t *, int *); -#define xfs_trans_commit(tp, flags, lsn) \ - _xfs_trans_commit(tp, flags, lsn, NULL) +#define xfs_trans_commit(tp, flags) _xfs_trans_commit(tp, flags, NULL) void xfs_trans_cancel(xfs_trans_t *, int); void xfs_trans_ail_init(struct xfs_mount *); xfs_lsn_t xfs_trans_push_ail(struct xfs_mount *, xfs_lsn_t); Index: linux/fs/xfs/xfs_utils.c =================================================================== --- linux/fs/xfs.orig/xfs_utils.c +++ linux/fs/xfs/xfs_utils.c @@ -222,7 +222,7 @@ xfs_dir_ialloc( } ntp = xfs_trans_dup(tp); - code = xfs_trans_commit(tp, 0, NULL); + code = xfs_trans_commit(tp, 0); tp = ntp; if (committed != NULL) { *committed = 1; @@ -460,8 +460,7 @@ xfs_truncate_file( XFS_TRANS_ABORT); } else { xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, - NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); } xfs_iunlock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL); Index: linux/fs/xfs/xfs_vfsops.c =================================================================== --- linux/fs/xfs.orig/xfs_vfsops.c +++ linux/fs/xfs/xfs_vfsops.c @@ -1539,7 +1539,7 @@ xfs_syncsub( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); xfs_trans_ihold(tp, ip); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); xfs_iunlock(ip, XFS_ILOCK_EXCL); xfs_log_force(mp, (xfs_lsn_t)0, log_flags); } Index: linux/fs/xfs/xfs_vnodeops.c =================================================================== --- linux/fs/xfs.orig/xfs_vnodeops.c +++ linux/fs/xfs/xfs_vnodeops.c @@ -873,7 +873,7 @@ xfs_setattr( if (mp->m_flags & XFS_MOUNT_WSYNC) xfs_trans_set_sync(tp); - code = xfs_trans_commit(tp, commit_flags, NULL); + code = xfs_trans_commit(tp, commit_flags); } /* @@ -1176,7 +1176,7 @@ xfs_fsync( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); if (flag & FSYNC_WAIT) xfs_trans_set_sync(tp); - error = _xfs_trans_commit(tp, 0, NULL, &log_flushed); + error = _xfs_trans_commit(tp, 0, &log_flushed); xfs_iunlock(ip, XFS_ILOCK_EXCL); } @@ -1291,8 +1291,7 @@ xfs_inactive_free_eofblocks( XFS_TRANS_ABORT)); } else { error = xfs_trans_commit(tp, - XFS_TRANS_RELEASE_LOG_RES, - NULL); + XFS_TRANS_RELEASE_LOG_RES); } xfs_iunlock(ip, XFS_IOLOCK_EXCL | XFS_ILOCK_EXCL); } @@ -1406,7 +1405,7 @@ xfs_inactive_symlink_rmt( * we need to unlock the inode since the new transaction doesn't * have the inode attached. */ - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); tp = ntp; if (error) { ASSERT(XFS_FORCED_SHUTDOWN(mp)); @@ -1503,7 +1502,7 @@ xfs_inactive_attrs( tp = *tpp; mp = ip->i_mount; ASSERT(ip->i_d.di_forkoff != 0); - xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); xfs_iunlock(ip, XFS_ILOCK_EXCL); error = xfs_attr_inactive(ip); @@ -1790,7 +1789,7 @@ xfs_inactive( * nothing we can do except to try to keep going. */ (void) xfs_bmap_finish(&tp, &free_list, &committed); - (void) xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + (void) xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); } /* * Release the dquots held by inode, if any. @@ -2026,7 +2025,7 @@ xfs_create( goto abort_rele; } - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (error) { IRELE(ip); tp = NULL; @@ -2511,7 +2510,7 @@ xfs_remove( goto error_rele; } - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (error) { IRELE(ip); goto std_return; @@ -2719,7 +2718,7 @@ xfs_link( goto abort_return; } - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (error) goto std_return; @@ -2936,7 +2935,7 @@ xfs_mkdir( goto error2; } - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); XFS_QM_DQRELE(mp, udqp); XFS_QM_DQRELE(mp, gdqp); if (error) { @@ -3190,7 +3189,7 @@ xfs_rmdir( goto std_return; } - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (error) { IRELE(cdp); goto std_return; @@ -3535,7 +3534,7 @@ xfs_symlink( if (error) { goto error2; } - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); XFS_QM_DQRELE(mp, udqp); XFS_QM_DQRELE(mp, gdqp); @@ -3790,7 +3789,7 @@ xfs_set_dmattrs ( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); IHOLD(ip); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); return error; } @@ -4148,7 +4147,7 @@ retry: goto error0; } - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); xfs_iunlock(ip, XFS_ILOCK_EXCL); if (error) { break; @@ -4455,7 +4454,7 @@ xfs_free_file_space( goto error0; } - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); xfs_iunlock(ip, XFS_ILOCK_EXCL); } @@ -4649,7 +4648,7 @@ xfs_change_file_space( xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); xfs_trans_set_sync(tp); - error = xfs_trans_commit(tp, 0, NULL); + error = xfs_trans_commit(tp, 0); xfs_iunlock(ip, XFS_ILOCK_EXCL); From owner-xfs@oss.sgi.com Tue Feb 6 21:03:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Feb 2007 21:03:37 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1753O3c023824 for ; Tue, 6 Feb 2007 21:03:25 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 914E118003EF5 for ; Tue, 6 Feb 2007 23:03:24 -0600 (CST) Message-ID: <45C95D9C.7080904@sandeen.net> Date: Tue, 06 Feb 2007 23:03:24 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] remove unused "aendp" arg to xfs_dir2_data_freescan Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10595 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 5431 Lines: 158 the "aendp" arg to xfs_dir2_data_freescan is always NULL, remove it. xfs_dir2_block.c | 14 +++++--------- xfs_dir2_data.c | 7 ++----- xfs_dir2_data.h | 2 +- xfs_dir2_leaf.c | 7 +++---- xfs_dir2_node.c | 4 ++-- 5 files changed, 13 insertions(+), 21 deletions(-) Signed-off-by: Eric Sandeen Index: linux/fs/xfs/xfs_dir2_block.c =================================================================== --- linux/fs/xfs.orig/xfs_dir2_block.c +++ linux/fs/xfs/xfs_dir2_block.c @@ -282,8 +282,7 @@ xfs_dir2_block_addname( * This needs to happen before the next call to use_free. */ if (needscan) { - xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, - &needlog, NULL); + xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog); needscan = 0; } } @@ -333,7 +332,7 @@ xfs_dir2_block_addname( */ if (needscan) { xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, - &needlog, NULL); + &needlog); needscan = 0; } /* @@ -418,8 +417,7 @@ xfs_dir2_block_addname( * Clean up the bestfree array and log the header, tail, and entry. */ if (needscan) - xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog, - NULL); + xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog); if (needlog) xfs_dir2_data_log_header(tp, bp); xfs_dir2_block_log_tail(tp, bp); @@ -798,8 +796,7 @@ xfs_dir2_block_removename( * Fix up bestfree, log the header if necessary. */ if (needscan) - xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog, - NULL); + xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog); if (needlog) xfs_dir2_data_log_header(tp, bp); xfs_dir2_data_check(dp, bp); @@ -996,8 +993,7 @@ xfs_dir2_leaf_to_block( * Scan the bestfree if we need it and log the data block header. */ if (needscan) - xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog, - NULL); + xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog); if (needlog) xfs_dir2_data_log_header(tp, dbp); /* Index: linux/fs/xfs/xfs_dir2_data.c =================================================================== --- linux/fs/xfs.orig/xfs_dir2_data.c +++ linux/fs/xfs/xfs_dir2_data.c @@ -324,8 +324,7 @@ void xfs_dir2_data_freescan( xfs_mount_t *mp, /* filesystem mount point */ xfs_dir2_data_t *d, /* data block pointer */ - int *loghead, /* out: log data header */ - char *aendp) /* in: caller's endp */ + int *loghead) /* out: log data header */ { xfs_dir2_block_tail_t *btp; /* block tail */ xfs_dir2_data_entry_t *dep; /* active data entry */ @@ -346,9 +345,7 @@ xfs_dir2_data_freescan( * Set up pointers. */ p = (char *)d->u; - if (aendp) - endp = aendp; - else if (be32_to_cpu(d->hdr.magic) == XFS_DIR2_BLOCK_MAGIC) { + if (be32_to_cpu(d->hdr.magic) == XFS_DIR2_BLOCK_MAGIC) { btp = XFS_DIR2_BLOCK_TAIL_P(mp, (xfs_dir2_block_t *)d); endp = (char *)XFS_DIR2_BLOCK_LEAF_P(btp); } else Index: linux/fs/xfs/xfs_dir2_data.h =================================================================== --- linux/fs/xfs.orig/xfs_dir2_data.h +++ linux/fs/xfs/xfs_dir2_data.h @@ -166,7 +166,7 @@ extern xfs_dir2_data_free_t *xfs_dir2_da extern xfs_dir2_data_free_t *xfs_dir2_data_freeinsert(xfs_dir2_data_t *d, xfs_dir2_data_unused_t *dup, int *loghead); extern void xfs_dir2_data_freescan(struct xfs_mount *mp, xfs_dir2_data_t *d, - int *loghead, char *aendp); + int *loghead); extern int xfs_dir2_data_init(struct xfs_da_args *args, xfs_dir2_db_t blkno, struct xfs_dabuf **bpp); extern void xfs_dir2_data_log_entry(struct xfs_trans *tp, struct xfs_dabuf *bp, Index: linux/fs/xfs/xfs_dir2_leaf.c =================================================================== --- linux/fs/xfs.orig/xfs_dir2_leaf.c +++ linux/fs/xfs/xfs_dir2_leaf.c @@ -133,8 +133,7 @@ xfs_dir2_block_to_leaf( */ block->hdr.magic = cpu_to_be32(XFS_DIR2_DATA_MAGIC); if (needscan) - xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog, - NULL); + xfs_dir2_data_freescan(mp, (xfs_dir2_data_t *)block, &needlog); /* * Set up leaf tail and bests table. */ @@ -414,7 +413,7 @@ xfs_dir2_leaf_addname( * Need to scan fix up the bestfree table. */ if (needscan) - xfs_dir2_data_freescan(mp, data, &needlog, NULL); + xfs_dir2_data_freescan(mp, data, &needlog); /* * Need to log the data block's header. */ @@ -1496,7 +1495,7 @@ xfs_dir2_leaf_removename( * log the data block header if necessary. */ if (needscan) - xfs_dir2_data_freescan(mp, data, &needlog, NULL); + xfs_dir2_data_freescan(mp, data, &needlog); if (needlog) xfs_dir2_data_log_header(tp, dbp); /* Index: linux/fs/xfs/xfs_dir2_node.c =================================================================== --- linux/fs/xfs.orig/xfs_dir2_node.c +++ linux/fs/xfs/xfs_dir2_node.c @@ -904,7 +904,7 @@ xfs_dir2_leafn_remove( * Log the data block header if needed. */ if (needscan) - xfs_dir2_data_freescan(mp, data, &needlog, NULL); + xfs_dir2_data_freescan(mp, data, &needlog); if (needlog) xfs_dir2_data_log_header(tp, dbp); xfs_dir2_data_check(dp, dbp); @@ -1705,7 +1705,7 @@ xfs_dir2_node_addname_int( * Rescan the block for bestfree if needed. */ if (needscan) - xfs_dir2_data_freescan(mp, data, &needlog, NULL); + xfs_dir2_data_freescan(mp, data, &needlog); /* * Log the data block header if needed. */ From owner-xfs@oss.sgi.com Tue Feb 6 21:06:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Feb 2007 21:06:13 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1755w3c024523 for ; Tue, 6 Feb 2007 21:06:01 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 5C37018003EF5 for ; Tue, 6 Feb 2007 23:05:58 -0600 (CST) Message-ID: <45C95E36.7020200@sandeen.net> Date: Tue, 06 Feb 2007 23:05:58 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] remove more misc. unused args Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10596 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 4615 Lines: 144 more misc. unused args xfs_bmap.c | 10 +++------- xfs_log_recover.c | 8 +++----- xfs_vnodeops.c | 5 ++--- 3 files changed, 8 insertions(+), 15 deletions(-) Signed-off-by: Eric Sandeen Index: linux/fs/xfs/xfs_bmap.c =================================================================== --- linux/fs/xfs.orig/xfs_bmap.c +++ linux/fs/xfs/xfs_bmap.c @@ -130,7 +130,6 @@ STATIC int /* error */ xfs_bmap_add_extent_hole_delay( xfs_inode_t *ip, /* incore inode pointer */ xfs_extnum_t idx, /* extent number to update/insert */ - xfs_btree_cur_t *cur, /* if null, not a btree */ xfs_bmbt_irec_t *new, /* new data to add to file extents */ int *logflagsp,/* inode logging flags */ xfs_extdelta_t *delta, /* Change made to incore extents */ @@ -399,7 +398,6 @@ xfs_bmap_count_leaves( STATIC int xfs_bmap_disk_count_leaves( - xfs_ifork_t *ifp, xfs_extnum_t idx, xfs_bmbt_block_t *block, int numrecs, @@ -580,7 +578,7 @@ xfs_bmap_add_extent( if (cur) ASSERT((cur->bc_private.b.flags & XFS_BTCUR_BPRV_WASDEL) == 0); - if ((error = xfs_bmap_add_extent_hole_delay(ip, idx, cur, new, + if ((error = xfs_bmap_add_extent_hole_delay(ip, idx, new, &logflags, delta, rsvd))) goto done; } @@ -1841,7 +1839,6 @@ STATIC int /* error */ xfs_bmap_add_extent_hole_delay( xfs_inode_t *ip, /* incore inode pointer */ xfs_extnum_t idx, /* extent number to update/insert */ - xfs_btree_cur_t *cur, /* if null, not a btree */ xfs_bmbt_irec_t *new, /* new data to add to file extents */ int *logflagsp, /* inode logging flags */ xfs_extdelta_t *delta, /* Change made to incore extents */ @@ -6425,8 +6422,8 @@ xfs_bmap_count_tree( for (;;) { nextbno = be64_to_cpu(block->bb_rightsib); numrecs = be16_to_cpu(block->bb_numrecs); - if (unlikely(xfs_bmap_disk_count_leaves(ifp, - 0, block, numrecs, count) < 0)) { + if (unlikely(xfs_bmap_disk_count_leaves(0, + block, numrecs, count) < 0)) { xfs_trans_brelse(tp, bp); XFS_ERROR_REPORT("xfs_bmap_count_tree(2)", XFS_ERRLEVEL_LOW, mp); @@ -6472,7 +6469,6 @@ xfs_bmap_count_leaves( */ int xfs_bmap_disk_count_leaves( - xfs_ifork_t *ifp, xfs_extnum_t idx, xfs_bmbt_block_t *block, int numrecs, Index: linux/fs/xfs/xfs_log_recover.c =================================================================== --- linux/fs/xfs.orig/xfs_log_recover.c +++ linux/fs/xfs/xfs_log_recover.c @@ -1509,7 +1509,6 @@ xlog_recover_insert_item_frontq( STATIC int xlog_recover_reorder_trans( - xlog_t *log, xlog_recover_t *trans) { xlog_recover_item_t *first_item, *itemq, *itemq_next; @@ -1867,7 +1866,6 @@ xlog_recover_do_inode_buffer( /*ARGSUSED*/ STATIC void xlog_recover_do_reg_buffer( - xfs_mount_t *mp, xlog_recover_item_t *item, xfs_buf_t *bp, xfs_buf_log_format_t *buf_f) @@ -2083,7 +2081,7 @@ xlog_recover_do_dquot_buffer( if (log->l_quotaoffs_flag & type) return; - xlog_recover_do_reg_buffer(mp, item, bp, buf_f); + xlog_recover_do_reg_buffer(item, bp, buf_f); } /* @@ -2184,7 +2182,7 @@ xlog_recover_do_buffer_trans( (XFS_BLI_UDQUOT_BUF|XFS_BLI_PDQUOT_BUF|XFS_BLI_GDQUOT_BUF)) { xlog_recover_do_dquot_buffer(mp, log, item, bp, buf_f); } else { - xlog_recover_do_reg_buffer(mp, item, bp, buf_f); + xlog_recover_do_reg_buffer(item, bp, buf_f); } if (error) return XFS_ERROR(error); @@ -2765,7 +2763,7 @@ xlog_recover_do_trans( int error = 0; xlog_recover_item_t *item, *first_item; - if ((error = xlog_recover_reorder_trans(log, trans))) + if ((error = xlog_recover_reorder_trans(trans))) return error; first_item = item = trans->r_itemq; do { Index: linux/fs/xfs/xfs_vnodeops.c =================================================================== --- linux/fs/xfs.orig/xfs_vnodeops.c +++ linux/fs/xfs/xfs_vnodeops.c @@ -2120,7 +2120,6 @@ int xfs_rm_attempts; STATIC int xfs_lock_dir_and_entry( xfs_inode_t *dp, - bhv_vname_t *dentry, xfs_inode_t *ip) /* inode of entry 'name' */ { int attempts; @@ -2439,7 +2438,7 @@ xfs_remove( return error; } - error = xfs_lock_dir_and_entry(dp, dentry, ip); + error = xfs_lock_dir_and_entry(dp, ip); if (error) { REMOVE_DEBUG_TRACE(__LINE__); xfs_trans_cancel(tp, cancel_flags); @@ -3095,7 +3094,7 @@ xfs_rmdir( * that the directory entry for the child directory inode has * not changed while we were obtaining a log reservation. */ - error = xfs_lock_dir_and_entry(dp, dentry, cdp); + error = xfs_lock_dir_and_entry(dp, cdp); if (error) { xfs_trans_cancel(tp, cancel_flags); IRELE(cdp); From owner-xfs@oss.sgi.com Wed Feb 7 02:38:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 02:38:52 -0800 (PST) X-Spam-oss-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17Acgm7005663 for ; Wed, 7 Feb 2007 02:38:44 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HEjsd-0000r5-8G; Wed, 07 Feb 2007 10:18:23 +0000 Date: Wed, 7 Feb 2007 10:18:23 +0000 From: Christoph Hellwig To: David Chinner Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC] Implement ->page_mkwrite for XFS Message-ID: <20070207101823.GA2703@infradead.org> References: <20070206225325.GP33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070206225325.GP33919298@melbourne.sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10597 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 3736 Lines: 120 On Wed, Feb 07, 2007 at 09:53:25AM +1100, David Chinner wrote: > Folks, > > I'm not sure of the exact locking rules and constraints for > ->page_mkwrite(), so I thought I better fish around for comments. > > With XFS, we need to hook pages being dirtied by mmap writes so that > we can attach buffers of the correct state tothe pages. This means > that when we write them back, the correct thing happens. > > For example, if you mmap an unwritten extent (preallocated), > currently your data will get written to disk but the extent will not > get converted to a written extent. IOWs, you lose the data because > when you read it back it will seen as unwritten and treated as a > hole. > > AFAICT, it is safe to lock the page during ->page_mkwrite and that > it is safe to issue I/O (e.g. metadata reads) to determine the > current state of the file. I am also assuming that, at this point, > we are not allowed to change the file size and so we have to be > careful in ->page_mkwrite we don't do that. What else have I missed > here? > > IOWs, I've basically treated ->page_mkwrite() as wrapper for > block_prepare_write/block_commit_write because they do all the > buffer mapping and state manipulation I think is necessary. Is it > safe to call these functions, or are there some other constraints we > have to work under here? > > Patch below. Comments? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > > --- > fs/xfs/linux-2.6/xfs_file.c | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-01-16 10:54:15.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-02-07 09:49:00.508017483 +1100 > @@ -446,6 +446,38 @@ xfs_file_open_exec( > } > #endif /* HAVE_FOP_OPEN_EXEC */ > > +/* > + * mmap()d file has taken write protection fault and is being made > + * writable. We can set the page state up correctly for a writable > + * page, which means we can do correct delalloc accounting (ENOSPC > + * checking!) and unwritten extent mapping. > + */ > +STATIC int > +xfs_vm_page_mkwrite( > + struct vm_area_struct *vma, > + struct page *page) > +{ > + struct inode *inode = vma->vm_file->f_path.dentry->d_inode; > + unsigned long end; > + int ret = 0; > + > + end = page->index + 1; > + end <<= PAGE_CACHE_SHIFT; > + if (end > i_size_read(inode)) > + end = i_size_read(inode) & ~PAGE_CACHE_MASK; > + else > + end = PAGE_CACHE_SIZE; > + > + lock_page(page); > + ret = block_prepare_write(page, 0, end, xfs_get_blocks); > + if (!ret) > + ret = block_commit_write(page, 0, end); > + unlock_page(page); > + > + return ret; > +} This looks to me. But given that this is generic code except for the get_block callback, shouldn't we put the guts into buffer.c and wire all filesystems up to use it? e.g. int block_page_mkwrite(struct vm_area_struct *vma, struct page *page, get_block_t get_block) { struct inode *inode = vma->vm_file->f_path.dentry->d_inode; unsigned long end; int ret = 0; if ((page->index + 1) << PAGE_CACHE_SHIFT > i_size_read(inode)) end = i_size_read(inode) & ~PAGE_CACHE_MASK; else end = PAGE_CACHE_SIZE; lock_page(page); ret = block_prepare_write(page, 0, end, block); if (!ret) ret = block_commit_write(page, 0, end); unlock_page(page); return ret; } and then in xfs and similar in other filesystems: STATIC int xfs_vm_page_mkwrite( struct vm_area_struct *vma, struct page *page) { return block_page_mkwrite(vma, page, xfs_get_blocks); } BTW, why is xfs_get_blocks not called xfs_get_block? From owner-xfs@oss.sgi.com Wed Feb 7 03:55:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 03:55:50 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l17Btem7016963 for ; Wed, 7 Feb 2007 03:55:43 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA00069; Wed, 7 Feb 2007 22:55:28 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l17BtP7Y83302184; Wed, 7 Feb 2007 22:55:25 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l17BtLTd115264399; Wed, 7 Feb 2007 22:55:21 +1100 (AEDT) Date: Wed, 7 Feb 2007 22:55:21 +1100 From: David Chinner To: Christoph Hellwig Cc: David Chinner , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC] Implement ->page_mkwrite for XFS Message-ID: <20070207115521.GH44411608@melbourne.sgi.com> References: <20070206225325.GP33919298@melbourne.sgi.com> <20070207101823.GA2703@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070207101823.GA2703@infradead.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 10598 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1569 Lines: 59 On Wed, Feb 07, 2007 at 10:18:23AM +0000, Christoph Hellwig wrote: > > This looks to me. But given that this is generic code except for the > get_block callback, shouldn't we put the guts into buffer.c and wire > all filesystems up to use it? e.g. > > > int block_page_mkwrite(struct vm_area_struct *vma, struct page *page, > get_block_t get_block) > { > struct inode *inode = vma->vm_file->f_path.dentry->d_inode; > unsigned long end; > int ret = 0; > > if ((page->index + 1) << PAGE_CACHE_SHIFT > i_size_read(inode)) > end = i_size_read(inode) & ~PAGE_CACHE_MASK; > else > end = PAGE_CACHE_SIZE; > > lock_page(page); > ret = block_prepare_write(page, 0, end, block); > if (!ret) > ret = block_commit_write(page, 0, end); > unlock_page(page); > return ret; > } > > and then in xfs and similar in other filesystems: > > STATIC int > xfs_vm_page_mkwrite( > struct vm_area_struct *vma, > struct page *page) > { > return block_page_mkwrite(vma, page, xfs_get_blocks); > } Yes, that can be done. block_page_mkwrite() would then go into fs/buffer.c? My patch originally had a bunch of other stuff and i wasn't sure that it could be done with generic code. I'll send an updated patch in a little while. > BTW, why is xfs_get_blocks not called xfs_get_block? I presume because it replaced the xfs_get_block() function when the block mapping callouts were modified to support mapping of multiple blocks. Maybe you should ask Nathan that question. ;) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Feb 7 04:49:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 04:49:39 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l17CnSm7030423 for ; Wed, 7 Feb 2007 04:49:30 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA01589; Wed, 7 Feb 2007 23:49:26 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l17CnO7Y115693441; Wed, 7 Feb 2007 23:49:24 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l17CnNKv114112872; Wed, 7 Feb 2007 23:49:23 +1100 (AEDT) Date: Wed, 7 Feb 2007 23:49:22 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality Message-ID: <20070207124922.GK44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 10599 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2717 Lines: 71 On Christoph's suggestion, take the guts of the proposed xfs_vm_page_mkwrite function and implement it as a generic core function as it used no specific XFS code at all. This allows any filesystem to easily hook the ->page_mkwrite() VM callout to allow them to set up pages dirtied by mmap writes correctly for later writeout. Signed-Off-By: Dave Chinner --- fs/buffer.c | 30 ++++++++++++++++++++++++++++++ include/linux/buffer_head.h | 2 ++ 2 files changed, 32 insertions(+) Index: 2.6.x-xfs-new/fs/buffer.c =================================================================== --- 2.6.x-xfs-new.orig/fs/buffer.c 2007-02-07 23:00:05.000000000 +1100 +++ 2.6.x-xfs-new/fs/buffer.c 2007-02-07 23:09:47.642356116 +1100 @@ -2194,6 +2194,36 @@ int generic_commit_write(struct file *fi return 0; } +/* + * block_page_mkwrite() is not allowed to change the file size as + * it gets called from a page fault handler when a page is first + * dirtied. Hence we must be careful to check for EOF conditions + * here. We set the page up correctly for a written page which means + * we get ENOSPC checking when writing into holes and correct + * delalloc and unwritten extent mapping on filesystems that support + * these features. + */ +int +block_page_mkwrite(struct vm_area_struct *vma, struct page *page, + get_block_t get_block) +{ + struct inode *inode = vma->vm_file->f_path.dentry->d_inode; + unsigned long end; + int ret = 0; + + if (((page->index + 1) << PAGE_CACHE_SHIFT) > i_size_read(inode)) + end = i_size_read(inode) & ~PAGE_CACHE_MASK; + else + end = PAGE_CACHE_SIZE; + + lock_page(page); + ret = block_prepare_write(page, 0, end, get_block); + if (!ret) + ret = block_commit_write(page, 0, end); + unlock_page(page); + + return ret; +} /* * nobh_prepare_write()'s prereads are special: the buffer_heads are freed Index: 2.6.x-xfs-new/include/linux/buffer_head.h =================================================================== --- 2.6.x-xfs-new.orig/include/linux/buffer_head.h 2007-02-07 23:00:02.000000000 +1100 +++ 2.6.x-xfs-new/include/linux/buffer_head.h 2007-02-07 23:12:33.156749344 +1100 @@ -206,6 +206,8 @@ int cont_prepare_write(struct page*, uns int generic_cont_expand(struct inode *inode, loff_t size); int generic_cont_expand_simple(struct inode *inode, loff_t size); int block_commit_write(struct page *page, unsigned from, unsigned to); +int block_page_mkwrite(struct vma_area_struct *vma, struct page *page, + get_block_t get_block); void block_sync_page(struct page *); sector_t generic_block_bmap(struct address_space *, sector_t, get_block_t *); int generic_commit_write(struct file *, struct page *, unsigned, unsigned); From owner-xfs@oss.sgi.com Wed Feb 7 04:52:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 04:52:30 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l17CqKm7031228 for ; Wed, 7 Feb 2007 04:52:21 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA01649; Wed, 7 Feb 2007 23:52:18 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l17CqG7Y116337476; Wed, 7 Feb 2007 23:52:16 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l17CqEn0116461199; Wed, 7 Feb 2007 23:52:14 +1100 (AEDT) Date: Wed, 7 Feb 2007 23:52:14 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 1 of 2] Implement XFS ->page_mkwrite() callout Message-ID: <20070207125214.GL44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 10600 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1579 Lines: 52 Use the generic block_page_mkrite() to implement the XFS ->page_mkwrite() callout. Signed-Off-By: Dave Chinner --- fs/xfs/linux-2.6/xfs_file.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-02-07 23:00:10.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-02-07 23:15:20.170880823 +1100 @@ -446,6 +446,20 @@ xfs_file_open_exec( } #endif /* HAVE_FOP_OPEN_EXEC */ +/* + * mmap()d file has taken write protection fault and is being made + * writable. We can set the page state up correctly for a writable + * page, which means we can do correct delalloc accounting (ENOSPC + * checking!) and unwritten extent mapping. + */ +STATIC int +xfs_vm_page_mkwrite( + struct vm_area_struct *vma, + struct page *page) +{ + return block_page_mkwrite(vma, page, xfs_get_blocks); +} + const struct file_operations xfs_file_operations = { .llseek = generic_file_llseek, .read = do_sync_read, @@ -503,12 +517,14 @@ const struct file_operations xfs_dir_fil static struct vm_operations_struct xfs_file_vm_ops = { .nopage = filemap_nopage, .populate = filemap_populate, + .page_mkwrite = xfs_vm_page_mkwrite, }; #ifdef HAVE_DMAPI static struct vm_operations_struct xfs_dmapi_file_vm_ops = { .nopage = xfs_vm_nopage, .populate = filemap_populate, + .page_mkwrite = xfs_vm_page_mkwrite, #ifdef HAVE_VMOP_MPROTECT .mprotect = xfs_vm_mprotect, #endif From owner-xfs@oss.sgi.com Wed Feb 7 04:55:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 04:55:43 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l17CtZm7032216 for ; Wed, 7 Feb 2007 04:55:37 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA01774; Wed, 7 Feb 2007 23:55:32 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l17CtU7Y115392669; Wed, 7 Feb 2007 23:55:31 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l17CtRs2116414395; Wed, 7 Feb 2007 23:55:27 +1100 (AEDT) Date: Wed, 7 Feb 2007 23:55:27 +1100 From: David Chinner To: xfs@oss.sgi.com Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality Message-ID: <20070207125527.GM44411608@melbourne.sgi.com> References: <20070207124922.GK44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070207124922.GK44411608@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 10601 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2814 Lines: 77 Mental Note: must remember to refresh patch after fixing compile errors. New patch attached. - On Christoph's suggestion, take the guts of the proposed xfs_vm_page_mkwrite function and implement it as a generic core function as it used no specific XFS code at all. This allows any filesystem to easily hook the ->page_mkwrite() VM callout to allow them to set up pages dirtied by mmap writes correctly for later writeout. Signed-Off-By: Dave Chinner --- fs/buffer.c | 30 ++++++++++++++++++++++++++++++ include/linux/buffer_head.h | 2 ++ 2 files changed, 32 insertions(+) Index: 2.6.x-xfs-new/fs/buffer.c =================================================================== --- 2.6.x-xfs-new.orig/fs/buffer.c 2007-02-07 23:00:05.000000000 +1100 +++ 2.6.x-xfs-new/fs/buffer.c 2007-02-07 23:09:47.642356116 +1100 @@ -2194,6 +2194,36 @@ int generic_commit_write(struct file *fi return 0; } +/* + * block_page_mkwrite() is not allowed to change the file size as + * it gets called from a page fault handler when a page is first + * dirtied. Hence we must be careful to check for EOF conditions + * here. We set the page up correctly for a written page which means + * we get ENOSPC checking when writing into holes and correct + * delalloc and unwritten extent mapping on filesystems that support + * these features. + */ +int +block_page_mkwrite(struct vm_area_struct *vma, struct page *page, + get_block_t get_block) +{ + struct inode *inode = vma->vm_file->f_path.dentry->d_inode; + unsigned long end; + int ret = 0; + + if (((page->index + 1) << PAGE_CACHE_SHIFT) > i_size_read(inode)) + end = i_size_read(inode) & ~PAGE_CACHE_MASK; + else + end = PAGE_CACHE_SIZE; + + lock_page(page); + ret = block_prepare_write(page, 0, end, get_block); + if (!ret) + ret = block_commit_write(page, 0, end); + unlock_page(page); + + return ret; +} /* * nobh_prepare_write()'s prereads are special: the buffer_heads are freed Index: 2.6.x-xfs-new/include/linux/buffer_head.h =================================================================== --- 2.6.x-xfs-new.orig/include/linux/buffer_head.h 2007-02-07 23:00:02.000000000 +1100 +++ 2.6.x-xfs-new/include/linux/buffer_head.h 2007-02-07 23:19:25.110816993 +1100 @@ -206,6 +206,8 @@ int cont_prepare_write(struct page*, uns int generic_cont_expand(struct inode *inode, loff_t size); int generic_cont_expand_simple(struct inode *inode, loff_t size); int block_commit_write(struct page *page, unsigned from, unsigned to); +int block_page_mkwrite(struct vm_area_struct *vma, struct page *page, + get_block_t get_block); void block_sync_page(struct page *); sector_t generic_block_bmap(struct address_space *, sector_t, get_block_t *); int generic_commit_write(struct file *, struct page *, unsigned, unsigned); From owner-xfs@oss.sgi.com Wed Feb 7 05:05:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 05:05:36 -0800 (PST) X-Spam-oss-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17D5Sm7002340 for ; Wed, 7 Feb 2007 05:05:30 -0800 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l17Cskb2007812 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 7 Feb 2007 13:54:46 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l17Csk9E007810 for xfs@oss.sgi.com; Wed, 7 Feb 2007 13:54:46 +0100 Date: Wed, 7 Feb 2007 13:54:46 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: Re: [PATCH] use struct kvec in struct uio Message-ID: <20070207125446.GB7740@lst.de> References: <20061129154607.GB6400@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061129154607.GB6400@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 10602 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 1734 Lines: 49 On Wed, Nov 29, 2006 at 04:46:07PM +0100, Christoph Hellwig wrote: > All but one useage of struct uio are for kernel pointers, so let's use > struct kvec instead of struct iovec. Because readlink by handle still > uses it with a user pointer we still have two sparse warnings, but the > noise level is reduced quite a bit by this. ping? > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6/fs/xfs/support/move.h > =================================================================== > --- linux-2.6.orig/fs/xfs/support/move.h 2006-11-29 16:27:25.000000000 +0100 > +++ linux-2.6/fs/xfs/support/move.h 2006-11-29 16:30:18.000000000 +0100 > @@ -55,7 +55,7 @@ > }; > > struct uio { > - struct iovec *uio_iov; /* pointer to array of iovecs */ > + struct kvec *uio_iov; /* pointer to array of iovecs */ > int uio_iovcnt; /* number of iovecs in array */ > xfs_off_t uio_offset; /* offset in file this uio corresponds to */ > int uio_resid; /* residual i/o count */ > @@ -63,7 +63,7 @@ > }; > > typedef struct uio uio_t; > -typedef struct iovec iovec_t; > +typedef struct kvec iovec_t; > > extern int xfs_uio_read (caddr_t, size_t, uio_t *); > > Index: linux-2.6/fs/xfs/linux-2.6/xfs_ioctl.c > =================================================================== > --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2006-11-29 16:33:37.000000000 +0100 > +++ linux-2.6/fs/xfs/linux-2.6/xfs_ioctl.c 2006-11-29 16:34:43.000000000 +0100 > @@ -388,7 +388,7 @@ > aiov.iov_len = olen; > aiov.iov_base = hreq.ohandle; > > - auio.uio_iov = &aiov; > + auio.uio_iov = (struct kvec *)&aiov; > auio.uio_iovcnt = 1; > auio.uio_offset = 0; > auio.uio_segflg = UIO_USERSPACE; ---end quoted text--- From owner-xfs@oss.sgi.com Wed Feb 7 05:05:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 05:05:40 -0800 (PST) X-Spam-oss-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17D5Sm9002340 for ; Wed, 7 Feb 2007 05:05:32 -0800 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l17Csbb2007791 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 7 Feb 2007 13:54:38 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l17Csb8m007789 for xfs@oss.sgi.com; Wed, 7 Feb 2007 13:54:37 +0100 Date: Wed, 7 Feb 2007 13:54:37 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: Re: [PATCH] fix sparse warning in xfs_da_btree.c Message-ID: <20070207125437.GA7740@lst.de> References: <20061129154441.GA6400@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061129154441.GA6400@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 10603 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 977 Lines: 28 On Wed, Nov 29, 2006 at 04:44:41PM +0100, Christoph Hellwig wrote: > The first use in xfs_da_node_lookup_int would have to be __be32. > But we can just remove this temporary variable use completely and > make sparse happy. The variable is used later in the function for > a native endian variable so we'll have to keep it. ping? > > > Signed-off-by: Christoph Hellwig > > diff --git a/fs/xfs/xfs_da_btree.c b/fs/xfs/xfs_da_btree.c > index a68bc1f..cccf69e 100644 > --- a/fs/xfs/xfs_da_btree.c > +++ b/fs/xfs/xfs_da_btree.c > @@ -1090,8 +1090,7 @@ xfs_da_node_lookup_int(xfs_da_state_t *s > if (blk->magic == XFS_DA_NODE_MAGIC) { > node = blk->bp->data; > max = be16_to_cpu(node->hdr.count); > - btreehashval = node->btree[max-1].hashval; > - blk->hashval = be32_to_cpu(btreehashval); > + blk->hashval = be32_to_cpu(node->btree[max-1].hashval); > > /* > * Binary search. (note: small blocks will skip loop) ---end quoted text--- From owner-xfs@oss.sgi.com Wed Feb 7 05:16:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 05:16:34 -0800 (PST) X-Spam-oss-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from extu-mxob-2.symantec.com (extu-mxob-2.symantec.com [216.10.194.135]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17DGRm7005471 for ; Wed, 7 Feb 2007 05:16:28 -0800 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 1C04938C4AD; Wed, 7 Feb 2007 05:11:32 -0800 (PST) X-AuditID: d80ac287-9dae7bb000007e48-34-45c9d0039205 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id BA06F348002; Wed, 7 Feb 2007 05:11:31 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HEmQW-0004Th-26; Wed, 07 Feb 2007 05:01:32 -0800 Received: from megami.veritas.com ([10.137.16.7]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Feb 2007 05:00:19 -0800 Received: from blonde.wat.veritas.com([10.10.97.7]) (3857 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Wed, 7 Feb 2007 05:00:19 -0800 (PST) (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30) Date: Wed, 7 Feb 2007 13:00:28 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@blonde.wat.veritas.com To: David Chinner cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality In-Reply-To: <20070207124922.GK44411608@melbourne.sgi.com> Message-ID: References: <20070207124922.GK44411608@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Feb 2007 13:00:19.0699 (UTC) FILETIME=[EBAFDC30:01C74AB7] X-Brightmail-Tracker: AAAAAA== X-archive-position: 10604 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hugh@veritas.com Precedence: bulk X-list: xfs Content-Length: 3085 Lines: 79 On Wed, 7 Feb 2007, David Chinner wrote: > On Christoph's suggestion, take the guts of the proposed > xfs_vm_page_mkwrite function and implement it as a generic > core function as it used no specific XFS code at all. > > This allows any filesystem to easily hook the ->page_mkwrite() > VM callout to allow them to set up pages dirtied by mmap > writes correctly for later writeout. > > Signed-Off-By: Dave Chinner I'm worried about concurrent truncation. Isn't it the case that i_mutex is held when prepare_write and commit_write are normally called? But not here when page_mkwrite is called. Hugh > > --- > fs/buffer.c | 30 ++++++++++++++++++++++++++++++ > include/linux/buffer_head.h | 2 ++ > 2 files changed, 32 insertions(+) > > Index: 2.6.x-xfs-new/fs/buffer.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/buffer.c 2007-02-07 23:00:05.000000000 +1100 > +++ 2.6.x-xfs-new/fs/buffer.c 2007-02-07 23:09:47.642356116 +1100 > @@ -2194,6 +2194,36 @@ int generic_commit_write(struct file *fi > return 0; > } > > +/* > + * block_page_mkwrite() is not allowed to change the file size as > + * it gets called from a page fault handler when a page is first > + * dirtied. Hence we must be careful to check for EOF conditions > + * here. We set the page up correctly for a written page which means > + * we get ENOSPC checking when writing into holes and correct > + * delalloc and unwritten extent mapping on filesystems that support > + * these features. > + */ > +int > +block_page_mkwrite(struct vm_area_struct *vma, struct page *page, > + get_block_t get_block) > +{ > + struct inode *inode = vma->vm_file->f_path.dentry->d_inode; > + unsigned long end; > + int ret = 0; > + > + if (((page->index + 1) << PAGE_CACHE_SHIFT) > i_size_read(inode)) > + end = i_size_read(inode) & ~PAGE_CACHE_MASK; > + else > + end = PAGE_CACHE_SIZE; > + > + lock_page(page); > + ret = block_prepare_write(page, 0, end, get_block); > + if (!ret) > + ret = block_commit_write(page, 0, end); > + unlock_page(page); > + > + return ret; > +} > > /* > * nobh_prepare_write()'s prereads are special: the buffer_heads are freed > Index: 2.6.x-xfs-new/include/linux/buffer_head.h > =================================================================== > --- 2.6.x-xfs-new.orig/include/linux/buffer_head.h 2007-02-07 23:00:02.000000000 +1100 > +++ 2.6.x-xfs-new/include/linux/buffer_head.h 2007-02-07 23:12:33.156749344 +1100 > @@ -206,6 +206,8 @@ int cont_prepare_write(struct page*, uns > int generic_cont_expand(struct inode *inode, loff_t size); > int generic_cont_expand_simple(struct inode *inode, loff_t size); > int block_commit_write(struct page *page, unsigned from, unsigned to); > +int block_page_mkwrite(struct vma_area_struct *vma, struct page *page, > + get_block_t get_block); > void block_sync_page(struct page *); > sector_t generic_block_bmap(struct address_space *, sector_t, get_block_t *); > int generic_commit_write(struct file *, struct page *, unsigned, unsigned); From owner-xfs@oss.sgi.com Wed Feb 7 06:44:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 06:44:37 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l17EiRm7029446 for ; Wed, 7 Feb 2007 06:44:29 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA05097; Thu, 8 Feb 2007 01:44:20 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l17EiI7Y99822793; Thu, 8 Feb 2007 01:44:19 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l17EiG0i116913573; Thu, 8 Feb 2007 01:44:16 +1100 (AEDT) Date: Thu, 8 Feb 2007 01:44:15 +1100 From: David Chinner To: Hugh Dickins Cc: David Chinner , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality Message-ID: <20070207144415.GN44411608@melbourne.sgi.com> References: <20070207124922.GK44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 10605 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1397 Lines: 39 On Wed, Feb 07, 2007 at 01:00:28PM +0000, Hugh Dickins wrote: > On Wed, 7 Feb 2007, David Chinner wrote: > > > On Christoph's suggestion, take the guts of the proposed > > xfs_vm_page_mkwrite function and implement it as a generic > > core function as it used no specific XFS code at all. > > > > This allows any filesystem to easily hook the ->page_mkwrite() > > VM callout to allow them to set up pages dirtied by mmap > > writes correctly for later writeout. > > > > Signed-Off-By: Dave Chinner > > I'm worried about concurrent truncation. Isn't it the case that > i_mutex is held when prepare_write and commit_write are normally > called? But not here when page_mkwrite is called. I'm not holding i_mutex. I assumed that it was probably safe to do because we are likely to be reading the page off disk just before we call mkwrite and that has to be synchronised with truncate in some manner.... So, do I need to grab the i_mutex here? Is that safe to do that in the middle of a page fault? If we do race with a truncate and the page is now beyond EOF, what am I supposed to return? I'm fishing for what I'm supposed to be doing here because there's zero implementations of this callout in the kernel and the comments in the code explaining the interface constraints are non-existant.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Feb 7 07:56:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 07:56:55 -0800 (PST) X-Spam-oss-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_40 autolearn=ham version=3.2.0-pre1-r497472 Received: from extu-mxob-2.symantec.com (extu-mxob-2.symantec.com [216.10.194.135]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17Fujm7017910 for ; Wed, 7 Feb 2007 07:56:47 -0800 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 6078438C57E; Wed, 7 Feb 2007 08:07:55 -0800 (PST) X-AuditID: d80ac287-a257fbb000007e48-89-45c9f95b122f Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 403B9348003; Wed, 7 Feb 2007 08:07:55 -0800 (PST) Received: from [10.137.18.172] (helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1HEpBD-0002jA-PL; Wed, 07 Feb 2007 07:57:55 -0800 Received: from megami.veritas.com ([10.137.16.7]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Feb 2007 07:56:06 -0800 Received: from blonde.wat.veritas.com([10.10.97.7]) (3778 bytes) by megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Wed, 7 Feb 2007 07:56:05 -0800 (PST) (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30) Date: Wed, 7 Feb 2007 15:56:15 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@blonde.wat.veritas.com To: David Chinner cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality In-Reply-To: <20070207144415.GN44411608@melbourne.sgi.com> Message-ID: References: <20070207124922.GK44411608@melbourne.sgi.com> <20070207144415.GN44411608@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Feb 2007 15:56:06.0167 (UTC) FILETIME=[79DF2A70:01C74AD0] X-Brightmail-Tracker: AAAAAA== X-archive-position: 10608 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hugh@veritas.com Precedence: bulk X-list: xfs Content-Length: 2899 Lines: 66 On Thu, 8 Feb 2007, David Chinner wrote: > On Wed, Feb 07, 2007 at 01:00:28PM +0000, Hugh Dickins wrote: > > > > I'm worried about concurrent truncation. Isn't it the case that > > i_mutex is held when prepare_write and commit_write are normally > > called? But not here when page_mkwrite is called. > > I'm not holding i_mutex. I assumed that it was probably safe to do > because we are likely to be reading the page off disk just before we > call mkwrite and that has to be synchronised with truncate in some > manner.... "assumed"..."probably"..."likely"..."just before"..."in some manner" doesn't sound very safe, does it :-? The well-established paths are almost safe against truncation (I insert "almost" there because although we like to think they're entirely safe, from time to time a hole is discovered, and Nick has been wrestling with filling them for some while now). But page_mkwrite is something new: so far, it's up to the implementor (the filesystem) to work out how to guard against truncation. > > So, do I need to grab the i_mutex here? Is that safe to do that in > the middle of a page fault? It's certainly easier to think about if you don't grab i_mutex there: sys_msync used to take i_mutex within down_read of mmap_sem, but we were quite happy to get rid of that, because usually it's down_read of mmap_sem within i_mutex (page fault when writing from userspace to file). I can't at this moment put my finger on an actual deadlock if you take i_mutex in page_mkwrite, but it feels wrong: hmm, if you add another thread waiting to down_write the mmap_sem, I think you would be able to deadlock. You don't need to lock out all truncation, but you do need to lock out truncation of the page in question. Instead of your i_size checks, check page->mapping isn't NULL after the lock_page? But aside from the truncation issue, if prepare_write and commit_write are always called with i_mutex held at present, I'm doubtful whether you can provide a generic default page_mkwrite which calls them without. Which would take us back to grabbing i_mutex within page_mkwrite. Ugh. > If we do race with a truncate and the > page is now beyond EOF, what am I supposed to return? Something negative. Nothing presently reports the error code in question, it just does SIGBUS; but it would be better for the truncation case to avoid -ENOMEM and -ENOSPC, which could easily have meanings here. I don't see a good choice, so maybe -EINVAL. > > I'm fishing for what I'm supposed to be doing here because there's > zero implementations of this callout in the kernel and the comments > in the code explaining the interface constraints are > non-existant.... Well, you seem to be the first to implement it. Hmm, that's not true, David was: what magic saved him from addressing the truncation issue? Don't be surprised if it turns out page_mkwrite needs more thought. Hugh From owner-xfs@oss.sgi.com Wed Feb 7 08:49:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 08:49:09 -0800 (PST) X-Spam-oss-Status: No, score=-1.1 required=5.0 tests=BAYES_05 autolearn=ham version=3.2.0-pre1-r497472 Received: from rgminet02.oracle.com (rgminet02.oracle.com [148.87.113.119]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17Gmxm7003766 for ; Wed, 7 Feb 2007 08:49:00 -0800 Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by rgminet02.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l17FtAmE031931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 Feb 2007 08:55:10 -0700 Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l17FsxI8005632; Wed, 7 Feb 2007 08:54:59 -0700 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l17FsLoB006384; Wed, 7 Feb 2007 08:54:57 -0700 Received: from cpe-72-225-43-119.rochester.res.rr.com by rcsmt252.oracle.com with ESMTP id 2429294361170863587; Wed, 07 Feb 2007 08:53:07 -0700 Date: Wed, 7 Feb 2007 10:52:45 -0500 From: Chris Mason To: David Chinner Cc: Hugh Dickins , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality Message-ID: <20070207155245.GB11967@think.oraclecorp.com> References: <20070207124922.GK44411608@melbourne.sgi.com> <20070207144415.GN44411608@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070207144415.GN44411608@melbourne.sgi.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Whitelist: TRUE X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-archive-position: 10610 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chris.mason@oracle.com Precedence: bulk X-list: xfs Content-Length: 1762 Lines: 42 On Thu, Feb 08, 2007 at 01:44:15AM +1100, David Chinner wrote: > On Wed, Feb 07, 2007 at 01:00:28PM +0000, Hugh Dickins wrote: > > On Wed, 7 Feb 2007, David Chinner wrote: > > > > > On Christoph's suggestion, take the guts of the proposed > > > xfs_vm_page_mkwrite function and implement it as a generic > > > core function as it used no specific XFS code at all. > > > > > > This allows any filesystem to easily hook the ->page_mkwrite() > > > VM callout to allow them to set up pages dirtied by mmap > > > writes correctly for later writeout. > > > > > > Signed-Off-By: Dave Chinner > > > > I'm worried about concurrent truncation. Isn't it the case that > > i_mutex is held when prepare_write and commit_write are normally > > called? But not here when page_mkwrite is called. > > I'm not holding i_mutex. I assumed that it was probably safe to do > because we are likely to be reading the page off disk just before we > call mkwrite and that has to be synchronised with truncate in some > manner.... In general, commit_write is allowed to update i_size, and prepare/commit are called with i_mutex. block_prepare_write and block_commit_write both look safe to me for calling with only the page lock held. It more or less translates to: call get_block in a sane fashion and zero out the parts of the page past eof. But, if someone copies the code and puts their own fancy prepare/commit_write in there, they will get in trouble in a hurry... > > So, do I need to grab the i_mutex here? Is that safe to do that in > the middle of a page fault? If we do race with a truncate and the > page is now beyond EOF, what am I supposed to return? Should it check to make sure the page is still in the address space after locking it? -chris From owner-xfs@oss.sgi.com Wed Feb 7 09:58:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 09:58:10 -0800 (PST) X-Spam-oss-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17Hw2m7016092 for ; Wed, 7 Feb 2007 09:58:03 -0800 Received: from [134.15.160.5] (vpn-emea-sw-emea-160-5.emea.sgi.com [134.15.160.5]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id l17HPunc82022769; Wed, 7 Feb 2007 09:25:57 -0800 (PST) Message-ID: <45CA1327.2030005@sgi.com> Date: Wed, 07 Feb 2007 17:57:59 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] fix sparse warning in xfs_da_btree.c References: <20061129154441.GA6400@lst.de> <20070207125437.GA7740@lst.de> In-Reply-To: <20070207125437.GA7740@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10611 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 1629 Lines: 59 Christoph, I merged this change a while ago but it looks like the take message didn't make it to oss. mod xfs-linux-melb:xfs-kern:27702a TAKE message ================================================ Subject: TAKE 954580 - fix sparse warning in xfs_da_btree.c Date: Tue Dec 12 13:15:55 AEDT 2006 Workarea: vpn-emea-sw-emea-160-4.emea.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: hch Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27702a fs/xfs/xfs_da_btree.c - 1.173 - changed Lachlan Christoph Hellwig wrote: > On Wed, Nov 29, 2006 at 04:44:41PM +0100, Christoph Hellwig wrote: > >>The first use in xfs_da_node_lookup_int would have to be __be32. >>But we can just remove this temporary variable use completely and >>make sparse happy. The variable is used later in the function for >>a native endian variable so we'll have to keep it. > > > ping? > > >> >>Signed-off-by: Christoph Hellwig >> >>diff --git a/fs/xfs/xfs_da_btree.c b/fs/xfs/xfs_da_btree.c >>index a68bc1f..cccf69e 100644 >>--- a/fs/xfs/xfs_da_btree.c >>+++ b/fs/xfs/xfs_da_btree.c >>@@ -1090,8 +1090,7 @@ xfs_da_node_lookup_int(xfs_da_state_t *s >> if (blk->magic == XFS_DA_NODE_MAGIC) { >> node = blk->bp->data; >> max = be16_to_cpu(node->hdr.count); >>- btreehashval = node->btree[max-1].hashval; >>- blk->hashval = be32_to_cpu(btreehashval); >>+ blk->hashval = be32_to_cpu(node->btree[max-1].hashval); >> >> /* >> * Binary search. (note: small blocks will skip loop) > > ---end quoted text--- > > From owner-xfs@oss.sgi.com Wed Feb 7 10:02:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 10:02:43 -0800 (PST) X-Spam-oss-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17I2Vm7017436 for ; Wed, 7 Feb 2007 10:02:32 -0800 Received: from [134.15.160.5] (vpn-emea-sw-emea-160-5.emea.sgi.com [134.15.160.5]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id l17HUPnc82015409; Wed, 7 Feb 2007 09:30:26 -0800 (PST) Message-ID: <45CA1435.7050100@sgi.com> Date: Wed, 07 Feb 2007 18:02:29 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] use struct kvec in struct uio References: <20061129154607.GB6400@lst.de> <20070207125446.GB7740@lst.de> In-Reply-To: <20070207125446.GB7740@lst.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10612 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 3071 Lines: 105 Christoph, Looks like another lost take message to oss. mod xfs-linux-melb:xfs-kern:27701a TAKE message ================================================ Subject: TAKE 954580 - use struct kvec in struct uio Date: Tue Dec 12 13:13:14 AEDT 2006 Workarea: vpn-emea-sw-emea-160-4.emea.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: hch Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27701a fs/xfs/support/move.h - 1.19 - changed fs/xfs/linux-2.6/xfs_ioctl.c - 1.140 - changed fs/xfs/dmapi/xfs_dm.c - 1.31 - changed - use struct kvec in struct uio I also included this change to fix a warning introduced with your patch. *** /usr/tmp/TmpDir.8968-0/fs/xfs/dmapi/xfs_dm.c_1.30 2007-02-07 18:00:52.000000000 +0000 --- /usr/tmp/TmpDir.8968-0/fs/xfs/dmapi/xfs_dm.c_1.31 2007-02-07 18:00:52.000000000 +0000 *************** *** 928,934 **** { int sink; struct uio auio; ! struct iovec aiov; int rval; *nreadp = 0; --- 928,934 ---- { int sink; struct uio auio; ! iovec_t aiov; int rval; *nreadp = 0; Lachlan Christoph Hellwig wrote: > On Wed, Nov 29, 2006 at 04:46:07PM +0100, Christoph Hellwig wrote: > >>All but one useage of struct uio are for kernel pointers, so let's use >>struct kvec instead of struct iovec. Because readlink by handle still >>uses it with a user pointer we still have two sparse warnings, but the >>noise level is reduced quite a bit by this. > > > ping? > > >> >>Signed-off-by: Christoph Hellwig >> >>Index: linux-2.6/fs/xfs/support/move.h >>=================================================================== >>--- linux-2.6.orig/fs/xfs/support/move.h 2006-11-29 16:27:25.000000000 +0100 >>+++ linux-2.6/fs/xfs/support/move.h 2006-11-29 16:30:18.000000000 +0100 >>@@ -55,7 +55,7 @@ >> }; >> >> struct uio { >>- struct iovec *uio_iov; /* pointer to array of iovecs */ >>+ struct kvec *uio_iov; /* pointer to array of iovecs */ >> int uio_iovcnt; /* number of iovecs in array */ >> xfs_off_t uio_offset; /* offset in file this uio corresponds to */ >> int uio_resid; /* residual i/o count */ >>@@ -63,7 +63,7 @@ >> }; >> >> typedef struct uio uio_t; >>-typedef struct iovec iovec_t; >>+typedef struct kvec iovec_t; >> >> extern int xfs_uio_read (caddr_t, size_t, uio_t *); >> >>Index: linux-2.6/fs/xfs/linux-2.6/xfs_ioctl.c >>=================================================================== >>--- linux-2.6.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2006-11-29 16:33:37.000000000 +0100 >>+++ linux-2.6/fs/xfs/linux-2.6/xfs_ioctl.c 2006-11-29 16:34:43.000000000 +0100 >>@@ -388,7 +388,7 @@ >> aiov.iov_len = olen; >> aiov.iov_base = hreq.ohandle; >> >>- auio.uio_iov = &aiov; >>+ auio.uio_iov = (struct kvec *)&aiov; >> auio.uio_iovcnt = 1; >> auio.uio_offset = 0; >> auio.uio_segflg = UIO_USERSPACE; > > ---end quoted text--- > > From owner-xfs@oss.sgi.com Wed Feb 7 11:31:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 11:32:00 -0800 (PST) X-Spam-oss-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_57,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r497472 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l17JVqm7031252 for ; Wed, 7 Feb 2007 11:31:53 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id 911A51A00B204; Wed, 7 Feb 2007 14:31:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 8F792A00226A for ; Wed, 7 Feb 2007 14:31:51 -0500 (EST) Date: Wed, 7 Feb 2007 14:31:51 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com Subject: xfs_growfs(?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 10614 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1603 Lines: 50 Anyone know the answer to this one? I have wondered the same thing. ---------- Forwarded message ---------- Date: Wed, 7 Feb 2007 12:16:55 -0600 From: "Discussion@SR" To: jpiszcz@lucidpixels.com Subject: Topic Subscription Reply Notification ( Discussion@SR ) jpiszcz, poodel has just posted a reply to a topic that you have subscribed to titled "RAID5 fileserver recommendations". ---------------------------------------------------------------------- QUOTE(jpiszcz @ Jan 3 2007, 12:08 PM) [snapback]237616[/snapback] Growing the XFS filesystem is a breeze: # xfs_growfs /raid5 ----------------------------- Just thought of one thing... when you add another disk to the set, doesn't that mess with the XFS parameters. Ideally, they would be tuned to your number of hard disks at creation time, but now they won't be? Is there a way to tune the XFS after creation? ---------------------------------------------------------------------- The topic can be found here: http://forums.storagereview.net/index.php?showtopic=24099&view=getnewpost If you have configured in your control panel to recieve immediate topic reply notifications, you may receive an email for each reply made to this topic. Otherwise, only 1 email is sent per board visit for each subscribed topic. This is to limit the amount of mail that is sent to your inbox. Unsubscribing: -------------- You can unsubscribe at any time by logging into your control panel and clicking on the "View Subscriptions" link. Regards, The Discussion@SR team. http://forums.storagereview.net/index.php From owner-xfs@oss.sgi.com Wed Feb 7 14:50:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 14:50:39 -0800 (PST) X-Spam-oss-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l17MoSm7005384 for ; Wed, 7 Feb 2007 14:50:30 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20197; Thu, 8 Feb 2007 09:50:19 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l17MoG7Y105136821; Thu, 8 Feb 2007 09:50:16 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l17MoDat117081408; Thu, 8 Feb 2007 09:50:13 +1100 (AEDT) Date: Thu, 8 Feb 2007 09:50:13 +1100 From: David Chinner To: Hugh Dickins Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality Message-ID: <20070207225013.GQ44411608@melbourne.sgi.com> References: <20070207124922.GK44411608@melbourne.sgi.com> <20070207144415.GN44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 10615 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 4233 Lines: 101 On Wed, Feb 07, 2007 at 03:56:15PM +0000, Hugh Dickins wrote: > On Thu, 8 Feb 2007, David Chinner wrote: > > On Wed, Feb 07, 2007 at 01:00:28PM +0000, Hugh Dickins wrote: > > > > > > I'm worried about concurrent truncation. Isn't it the case that > > > i_mutex is held when prepare_write and commit_write are normally > > > called? But not here when page_mkwrite is called. > > > > I'm not holding i_mutex. I assumed that it was probably safe to do > > because we are likely to be reading the page off disk just before we > > call mkwrite and that has to be synchronised with truncate in some > > manner.... > > "assumed"..."probably"..."likely"..."just before"..."in some manner" > doesn't sound very safe, does it :-? You're right, it doesn't sound safe, does it? Why do you think I posted the patches for comment? > But page_mkwrite is something new: so far, it's up to the implementor > (the filesystem) to work out how to guard against truncation. Ok. I can do that now I know I have to. > > So, do I need to grab the i_mutex here? Is that safe to do that in > > the middle of a page fault? > > It's certainly easier to think about if you don't grab i_mutex there: > sys_msync used to take i_mutex within down_read of mmap_sem, but we > were quite happy to get rid of that, because usually it's down_read > of mmap_sem within i_mutex (page fault when writing from userspace > to file). I can't at this moment put my finger on an actual deadlock > if you take i_mutex in page_mkwrite, but it feels wrong: hmm, if you > add another thread waiting to down_write the mmap_sem, I think you > would be able to deadlock. Right, so i_mutex is out. That needs to be commented in big flashing neon lights somewhere in the code. > You don't need to lock out all truncation, but you do need to lock > out truncation of the page in question. Instead of your i_size > checks, check page->mapping isn't NULL after the lock_page? Yes, that can be done, but we still need to know if part of the page is beyond EOF for when we call block_commit_write() and mark buffers dirty. Hence we need to check the inode size. I guess if we block the truncate with the page lock, then the inode size is not going to change until we unlock the page. If the inode size has already been changed but the page not yet removed from the mapping we'll be beyond EOF. So it seems to me that we can get away with not using the i_mutex in the generic code here. > But aside from the truncation issue, if prepare_write and commit_write > are always called with i_mutex held at present, I'm doubtful whether > you can provide a generic default page_mkwrite which calls them without. > Which would take us back to grabbing i_mutex within page_mkwrite. Ugh. The only thing that is asserted as a requirement for block_prepare_write is that the page is locked. Apart fromteh page truncation issue, it is safe to do this at least on XFS because it has internal locks that ensure sanity even when the i_mutex is not held. If a particular filesystem has different locking requirements, they can be met in the filesystem wrapper function (e.g. xfs_vm_page_mkwrite()) which calls block_page_mkwrite(). > > If we do race with a truncate and the > > page is now beyond EOF, what am I supposed to return? > > Something negative. Nothing presently reports the error code in > question, it just does SIGBUS; but it would be better for the > truncation case to avoid -ENOMEM and -ENOSPC, which could easily > have meanings here. I don't see a good choice, so maybe -EINVAL. Ok. > > I'm fishing for what I'm supposed to be doing here because there's > > zero implementations of this callout in the kernel and the comments > > in the code explaining the interface constraints are > > non-existant.... > > Well, you seem to be the first to implement it. Hmm, that's not true, > David was: what magic saved him from addressing the truncation issue? No idea. His code is not in mainline.... > Don't be surprised if it turns out page_mkwrite needs more thought. I'll add a patch to the series adding some comments on the restrictions placed on implementers of this function. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Feb 7 16:00:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 16:00:54 -0800 (PST) X-Spam-oss-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_57 autolearn=no version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1800hm7015331 for ; Wed, 7 Feb 2007 16:00:45 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22767; Thu, 8 Feb 2007 11:00:37 +1100 Message-Id: <200702080000.LAA22767@larry.melbourne.sgi.com> From: "Barry Naujok" To: "'Justin Piszcz'" , Subject: RE: xfs_growfs(?) Date: Thu, 8 Feb 2007 11:04:14 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcdK70DpJT6F9SinSSm13lL+gpvWbAAJQSFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: X-archive-position: 10616 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 2813 Lines: 91 Hi Justin, > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Justin Piszcz > Sent: Thursday, 8 February 2007 6:32 AM > To: xfs@oss.sgi.com > Subject: xfs_growfs(?) > > Anyone know the answer to this one? You can change the sunit/swidth for XFS at any time by modifying the mount options: From the mount(8) man page: -o sunit=,swidth= Used to specify the stripe unit and width for a RAID device or a stripe volume. value must be specified in 512-byte block units. If this option is not specified and the filesystem was made on a stripe volume or the stripe width or unit were specified for the RAID device at mkfs time, then the mount system call will restore the value from the superblock. For filesystems that are made directly on RAID devices, these options can be used to override the information in the superblock if the underlying disk layout changes after the filesystem has been created. The swidth option is required if the sunit option has been specified, and must be a multiple of the sunit value. Barry. > I have wondered the same thing. > > ---------- Forwarded message ---------- > Date: Wed, 7 Feb 2007 12:16:55 -0600 > From: "Discussion@SR" > To: jpiszcz@lucidpixels.com > Subject: Topic Subscription Reply Notification ( Discussion@SR ) > > jpiszcz, > > poodel has just posted a reply to a topic that you have > subscribed to titled "RAID5 fileserver recommendations". > > ---------------------------------------------------------------------- > QUOTE(jpiszcz @ Jan 3 2007, 12:08 PM) [snapback]237616[/snapback] > > Growing the XFS filesystem is a breeze: > > # xfs_growfs /raid5 > > > ----------------------------- > > > > Just thought of one thing... when you add another disk to the > set, doesn't that mess with the XFS parameters. Ideally, they > would be tuned to your number of hard disks at creation time, > but now they won't be? > > Is there a way to tune the XFS after creation? > ---------------------------------------------------------------------- > > The topic can be found here: > http://forums.storagereview.net/index.php?showtopic=24099&view =getnewpost > > > > If you have configured in your control panel to recieve > immediate topic reply notifications, you may receive an > email for each reply made to this topic. Otherwise, only 1 > email is sent per board visit for each subscribed topic. > This is to limit the amount of mail that is sent to your inbox. > > Unsubscribing: > -------------- > > You can unsubscribe at any time by logging into your control > panel and clicking on the "View Subscriptions" link. > > Regards, > > The Discussion@SR team. > http://forums.storagereview.net/index.php > > From owner-xfs@oss.sgi.com Wed Feb 7 18:34:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 18:34:30 -0800 (PST) X-Spam-oss-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from smtp105.mail.mud.yahoo.com (smtp105.mail.mud.yahoo.com [209.191.85.215]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l182YIm7006552 for ; Wed, 7 Feb 2007 18:34:19 -0800 Received: (qmail 59019 invoked from network); 8 Feb 2007 02:34:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qHgqfAxy3RyO6YTtHHLe6bsgDC8bcdXqgQwS8lYZrnbtifOzmcIlRTxtVxjWTNoKK6uJ9rp7Md6r6UFtJQ3RRSjP9LZYtHKAtgukg5Bls7+cWsyF6uMwsRfSFYRVfDloclMgMIYymovTOvn7nAIWxS81lpmZkEMwzUt+gmYVpNk= ; Received: from unknown (HELO ?192.168.0.1?) (nickpiggin@203.173.2.153 with plain) by smtp105.mail.mud.yahoo.com with SMTP; 8 Feb 2007 02:34:16 -0000 X-YMail-OSG: hl4vjYgVM1mAwvG.XcHczEFYkFzoQovac7t0IdPiMEzEwfmixNL6LZIjKslWK.29nL2ZphbEmCsaz3Zlu6KI_Ao3JHtwtRN4nICLu.V.lpHp_zJsUvI7apE_8fHdAPK3TdNe2noub.SqT3w- Message-ID: <45CA8C18.9020104@yahoo.com.au> Date: Thu, 08 Feb 2007 13:34:00 +1100 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007 Debian/1.7.12-1 X-Accept-Language: en MIME-Version: 1.0 To: Chris Mason CC: David Chinner , Hugh Dickins , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality References: <20070207124922.GK44411608@melbourne.sgi.com> <20070207144415.GN44411608@melbourne.sgi.com> <20070207155245.GB11967@think.oraclecorp.com> In-Reply-To: <20070207155245.GB11967@think.oraclecorp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10617 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nickpiggin@yahoo.com.au Precedence: bulk X-list: xfs Content-Length: 638 Lines: 20 Chris Mason wrote: > On Thu, Feb 08, 2007 at 01:44:15AM +1100, David Chinner wrote: >>So, do I need to grab the i_mutex here? Is that safe to do that in >>the middle of a page fault? If we do race with a truncate and the >>page is now beyond EOF, what am I supposed to return? > > > Should it check to make sure the page is still in the address space > after locking it? Yes. If the page was truncated/invalidated, then you can just return and the pagefault handler should notice that it has been removed from the page tables. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com From owner-xfs@oss.sgi.com Wed Feb 7 19:04:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Feb 2007 19:04:17 -0800 (PST) X-Spam-oss-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_50, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l18349m7010660 for ; Wed, 7 Feb 2007 19:04:10 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l181Vfn7006818 for ; Wed, 7 Feb 2007 20:31:41 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l181Vft8017243 for ; Wed, 7 Feb 2007 20:31:41 -0500 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l181Ve3p019859 for ; Wed, 7 Feb 2007 20:31:40 -0500 Message-ID: <45CA7D7B.3060307@redhat.com> Date: Wed, 07 Feb 2007 19:31:39 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] don't special-case 32MB machines Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10618 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@redhat.com Precedence: bulk X-list: xfs Content-Length: 4575 Lines: 131 This one may be a bit silly, but: All the special cases for 32MB machines probably aren't so useful anymore... Or maybe this points to the need to bump up the scaling points & sizes a bit? Also remove duplicate, unused XFS_MAX_RW_NBMAPS definitions in linux subdirs. linux-2.4/xfs_lrw.h | 5 ----- linux-2.6/xfs_lrw.h | 5 ----- xfs_log.c | 18 ++++-------------- xfs_mount.c | 11 +++-------- xfs_rw.h | 9 --------- 5 files changed, 7 insertions(+), 41 deletions(-) Signed-off-by: Eric Sandeen Index: linux/fs/xfs/xfs_log.c =================================================================== --- linux.orig/fs/xfs/xfs_log.c +++ linux/fs/xfs/xfs_log.c @@ -1012,10 +1012,7 @@ xlog_bdstrat_cb(struct xfs_buf *bp) /* * Return size of each in-core log record buffer. * - * Low memory machines only get 2 16KB buffers. We don't want to waste - * memory here. However, all other machines get at least 2 32KB buffers. - * The number is hard coded because we don't care about the minimum - * memory size, just 32MB systems. + * All machines get at least 2 32KB buffers. * * If the filesystem blocksize is too large, we may need to choose a * larger size since the directory code currently logs entire blocks. @@ -1070,17 +1067,10 @@ xlog_get_iclog_buffer_size(xfs_mount_t * } /* - * Special case machines that have less than 32MB of memory. - * All machines with more memory use 32KB buffers. + * All machines use 32KB buffers. */ - if (xfs_physmem <= btoc(32*1024*1024)) { - /* Don't change; min configuration */ - log->l_iclog_size = XLOG_RECORD_BSIZE; /* 16k */ - log->l_iclog_size_log = XLOG_RECORD_BSHIFT; - } else { - log->l_iclog_size = XLOG_BIG_RECORD_BSIZE; /* 32k */ - log->l_iclog_size_log = XLOG_BIG_RECORD_BSHIFT; - } + log->l_iclog_size = XLOG_BIG_RECORD_BSIZE; /* 32k */ + log->l_iclog_size_log = XLOG_BIG_RECORD_BSHIFT; /* the default log size is 16k or 32k which is one header sector */ log->l_iclog_hsize = BBSIZE; Index: linux/fs/xfs/xfs_mount.c =================================================================== --- linux.orig/fs/xfs/xfs_mount.c +++ linux/fs/xfs/xfs_mount.c @@ -802,15 +802,10 @@ xfs_mountfs( } /* - * Set the number of readahead buffers to use based on - * physical memory size. + * Set the number of readahead buffers to use. */ - if (xfs_physmem <= 4096) /* <= 16MB */ - mp->m_nreadaheads = XFS_RW_NREADAHEAD_16MB; - else if (xfs_physmem <= 8192) /* <= 32MB */ - mp->m_nreadaheads = XFS_RW_NREADAHEAD_32MB; - else - mp->m_nreadaheads = XFS_RW_NREADAHEAD_K32; + mp->m_nreadaheads = XFS_MAX_RW_NBMAPS; + if (sbp->sb_blocklog > readio_log) { mp->m_readio_log = sbp->sb_blocklog; } else { Index: linux/fs/xfs/xfs_rw.h =================================================================== --- linux.orig/fs/xfs/xfs_rw.h +++ linux/fs/xfs/xfs_rw.h @@ -28,15 +28,6 @@ struct xfs_mount; #define XFS_MAX_RW_NBMAPS 4 /* - * Counts of readahead buffers to use based on physical memory size. - * None of these should be more than XFS_MAX_RW_NBMAPS. - */ -#define XFS_RW_NREADAHEAD_16MB 2 -#define XFS_RW_NREADAHEAD_32MB 3 -#define XFS_RW_NREADAHEAD_K32 4 -#define XFS_RW_NREADAHEAD_K64 4 - -/* * Maximum size of a buffer that we\'ll map. Making this * too big will degrade performance due to the number of * pages which need to be gathered. Making it too small Index: linux/fs/xfs/linux-2.4/xfs_lrw.h =================================================================== --- linux.orig/fs/xfs/linux-2.4/xfs_lrw.h +++ linux/fs/xfs/linux-2.4/xfs_lrw.h @@ -69,11 +69,6 @@ extern void xfs_inval_cached_trace(struc #define xfs_inval_cached_trace(io, offset, len, first, last) #endif -/* - * Maximum count of bmaps used by read and write paths. - */ -#define XFS_MAX_RW_NBMAPS 4 - extern int xfs_bmap(struct bhv_desc *, xfs_off_t, ssize_t, int, struct xfs_iomap *, int *); extern int xfsbdstrat(struct xfs_mount *, struct xfs_buf *); Index: linux/fs/xfs/linux-2.6/xfs_lrw.h =================================================================== --- linux.orig/fs/xfs/linux-2.6/xfs_lrw.h +++ linux/fs/xfs/linux-2.6/xfs_lrw.h @@ -71,11 +71,6 @@ extern void xfs_inval_cached_trace(struc #define xfs_inval_cached_trace(io, offset, len, first, last) #endif -/* - * Maximum count of bmaps used by read and write paths. - */ -#define XFS_MAX_RW_NBMAPS 4 - extern int xfs_bmap(struct bhv_desc *, xfs_off_t, ssize_t, int, struct xfs_iomap *, int *); extern int xfsbdstrat(struct xfs_mount *, struct xfs_buf *); From owner-xfs@oss.sgi.com Thu Feb 8 06:45:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Feb 2007 06:45:57 -0800 (PST) X-Spam-oss-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from agminet02.oracle.com (agminet02.oracle.com [141.146.126.229]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l18Ejim7006792 for ; Thu, 8 Feb 2007 06:45:49 -0800 Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) by agminet02.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l18DBYtc028880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Feb 2007 07:11:34 -0600 Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l18DBPt3025989; Thu, 8 Feb 2007 07:11:26 -0600 Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgmgw1.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l18CuRrc010711; Thu, 8 Feb 2007 06:11:24 -0700 Received: from cpe-72-225-43-119.rochester.res.rr.com by rcsmt252.oracle.com with ESMTP id 2431490221170940284; Thu, 08 Feb 2007 06:11:24 -0700 Date: Thu, 8 Feb 2007 08:11:00 -0500 From: Chris Mason To: David Chinner Cc: Hugh Dickins , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality Message-ID: <20070208131100.GH11967@think.oraclecorp.com> References: <20070207124922.GK44411608@melbourne.sgi.com> <20070207144415.GN44411608@melbourne.sgi.com> <20070207225013.GQ44411608@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070207225013.GQ44411608@melbourne.sgi.com> User-Agent: Mutt/1.5.12-2006-07-14 X-Whitelist: TRUE X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-archive-position: 10619 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chris.mason@oracle.com Precedence: bulk X-list: xfs Content-Length: 1477 Lines: 36 On Thu, Feb 08, 2007 at 09:50:13AM +1100, David Chinner wrote: > > You don't need to lock out all truncation, but you do need to lock > > out truncation of the page in question. Instead of your i_size > > checks, check page->mapping isn't NULL after the lock_page? > > Yes, that can be done, but we still need to know if part of > the page is beyond EOF for when we call block_commit_write() > and mark buffers dirty. Hence we need to check the inode size. > > I guess if we block the truncate with the page lock, then the > inode size is not going to change until we unlock the page. > If the inode size has already been changed but the page not yet > removed from the mapping we'll be beyond EOF. > > So it seems to me that we can get away with not using the i_mutex > in the generic code here. vmtruncate changes the inode size before waiting on any pages. So, i_size could change any time during page_mkwrite. Since the patch does: if (((page->index + 1) << PAGE_CACHE_SHIFT) > i_size_read(inode)) end = i_size_read(inode) & ~PAGE_CACHE_MASK; else end = PAGE_CACHE_SIZE; It would be a good idea to read i_size once and put it in a local var instead. The FS truncate op should be locking the last page in the file to make sure it is properly zero filled. The worst case should be that we zero too many bytes in page_mkwrite (expanding truncate past our current i_size), but at least it won't expose stale data. -chris From owner-xfs@oss.sgi.com Thu Feb 8 11:53:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Feb 2007 11:53:55 -0800 (PST) X-Spam-oss-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l18Jrhm7014101 for ; Thu, 8 Feb 2007 11:53:44 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HFEvI-0000ah-Vb; Thu, 08 Feb 2007 19:27:12 +0000 Date: Thu, 8 Feb 2007 19:27:12 +0000 From: Christoph Hellwig To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH] don't special-case 32MB machines Message-ID: <20070208192712.GA1461@infradead.org> References: <45CA7D7B.3060307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45CA7D7B.3060307@redhat.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10620 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 422 Lines: 13 On Wed, Feb 07, 2007 at 07:31:39PM -0600, Eric Sandeen wrote: > This one may be a bit silly, but: > > All the special cases for 32MB machines probably aren't so useful anymore... > > Or maybe this points to the need to bump up the scaling points & sizes a > bit? > > Also remove duplicate, unused XFS_MAX_RW_NBMAPS definitions in linux > subdirs. Sounds good. Any chance you could kill off xfs_physmem completely? From owner-xfs@oss.sgi.com Thu Feb 8 12:33:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Feb 2007 12:33:21 -0800 (PST) X-Spam-oss-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l18KXAm7023671 for ; Thu, 8 Feb 2007 12:33:15 -0800 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id l18KX9b2003122 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Feb 2007 21:33:10 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id l18KX96m003120; Thu, 8 Feb 2007 21:33:09 +0100 Date: Thu, 8 Feb 2007 21:33:09 +0100 From: Christoph Hellwig To: Lachlan McIlroy Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] fix sparse warning in xfs_da_btree.c Message-ID: <20070208203309.GA3012@lst.de> References: <20061129154441.GA6400@lst.de> <20070207125437.GA7740@lst.de> <45CA1327.2030005@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45CA1327.2030005@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 10621 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 479 Lines: 12 On Wed, Feb 07, 2007 at 05:57:59PM +0000, Lachlan McIlroy wrote: > Christoph, > > I merged this change a while ago but it looks like the take message > didn't make it to oss. Ah, okay - thanks for putting this in. And we really should find a way to make the system send out TAKE messages automatically so that developers can't acidentally not send it out.. (and while we're at it make sure the diff is sent out in the message aswell as for most cvs/svn commit list setups..) From owner-xfs@oss.sgi.com Thu Feb 8 12:38:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Feb 2007 12:38:53 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l18Kckm7024463 for ; Thu, 8 Feb 2007 12:38:47 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l18KcVNn030708; Thu, 8 Feb 2007 15:38:32 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l18KcU0K012884; Thu, 8 Feb 2007 15:38:30 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l18KcUrr016580; Thu, 8 Feb 2007 15:38:30 -0500 Message-ID: <45CB8A61.6060902@redhat.com> Date: Thu, 08 Feb 2007 14:38:57 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (X11/20061219) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] don't special-case 32MB machines References: <45CA7D7B.3060307@redhat.com> <20070208192712.GA1461@infradead.org> In-Reply-To: <20070208192712.GA1461@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10622 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@redhat.com Precedence: bulk X-list: xfs Content-Length: 605 Lines: 20 Christoph Hellwig wrote: > On Wed, Feb 07, 2007 at 07:31:39PM -0600, Eric Sandeen wrote: >> This one may be a bit silly, but: >> >> All the special cases for 32MB machines probably aren't so useful anymore... >> >> Or maybe this points to the need to bump up the scaling points & sizes a >> bit? >> >> Also remove duplicate, unused XFS_MAX_RW_NBMAPS definitions in linux >> subdirs. > > Sounds good. Any chance you could kill off xfs_physmem completely? > Hm, why out of curiosity? Because you think xfs should never be looking at system memory, or because you don't like the name, or ...? -Eric From owner-xfs@oss.sgi.com Thu Feb 8 14:31:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Feb 2007 14:31:24 -0800 (PST) X-Spam-oss-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l18MVGm7005141 for ; Thu, 8 Feb 2007 14:31:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29365; Fri, 9 Feb 2007 09:31:07 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l18MV27Y118019119; Fri, 9 Feb 2007 09:31:03 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l18MUwEE114363823; Fri, 9 Feb 2007 09:30:58 +1100 (AEDT) Date: Fri, 9 Feb 2007 09:30:58 +1100 From: David Chinner To: Chris Mason Cc: David Chinner , Hugh Dickins , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 1 of 2] Implement generic block_page_mkwrite() functionality Message-ID: <20070208223058.GV44411608@melbourne.sgi.com> References: <20070207124922.GK44411608@melbourne.sgi.com> <20070207144415.GN44411608@melbourne.sgi.com> <20070207225013.GQ44411608@melbourne.sgi.com> <20070208131100.GH11967@think.oraclecorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070208131100.GH11967@think.oraclecorp.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 10623 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1289 Lines: 38 On Thu, Feb 08, 2007 at 08:11:00AM -0500, Chris Mason wrote: > On Thu, Feb 08, 2007 at 09:50:13AM +1100, David Chinner wrote: > > > You don't need to lock out all truncation, but you do need to lock > > > out truncation of the page in question. Instead of your i_size > > > checks, check page->mapping isn't NULL after the lock_page? > > > > Yes, that can be done, but we still need to know if part of > > the page is beyond EOF for when we call block_commit_write() > > and mark buffers dirty. Hence we need to check the inode size. > > > > I guess if we block the truncate with the page lock, then the > > inode size is not going to change until we unlock the page. > > If the inode size has already been changed but the page not yet > > removed from the mapping we'll be beyond EOF. > > > > So it seems to me that we can get away with not using the i_mutex > > in the generic code here. > > vmtruncate changes the inode size before waiting on any pages. So, > i_size could change any time during page_mkwrite. Which would put us beyond EOF. Ok. > It would be a good idea to read i_size once and put it in a local var > instead. Will do - I'll snap it once the page is locked.... Thanks Chris. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Feb 8 15:06:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Feb 2007 15:06:57 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l18N6lm7009160 for ; Thu, 8 Feb 2007 15:06:51 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00813; Fri, 9 Feb 2007 10:06:42 +1100 Message-ID: <45CB9EA6.9090301@sgi.com> Date: Fri, 09 Feb 2007 09:05:26 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: xfs mailing list Subject: PARTIAL TAKE 960369: XFS-QA-144-ERROR: get_bulkattr found 0 matching files (expected 50) in NUM loops Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10624 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 993 Lines: 23 A dmapi enabled xfs filesytem can be mounted with any of the alias mount options "dmapi", "xdsm" or "dmi". Libdm is missing a check for "dmi" hence the failure in xfs qa test 144. Date: Fri Feb 9 09:57:59 AEDT 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/xfs-cmds-pv960369 Inspected by: dgc Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:28053a dmapi/VERSION - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/VERSION.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h dmapi/doc/CHANGES - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/doc/CHANGES.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h dmapi/libdm/dm_handle2path.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/libdm/dm_handle2path.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h - pv 960369, rv dgc - libdm is missing a check for "dmi" mount option in get_mnt() From owner-xfs@oss.sgi.com Fri Feb 9 05:28:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Feb 2007 05:28:13 -0800 (PST) X-Spam-oss-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l19DS6m7010522 for ; Fri, 9 Feb 2007 05:28:07 -0800 Received: from linux01.gwdg.de ([134.76.13.21]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HFVBn-00087i-5M for xfs@oss.sgi.com; Fri, 09 Feb 2007 13:49:19 +0100 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id l19CnJsR007337 for ; Fri, 9 Feb 2007 13:49:21 +0100 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id l19CnIbG007330 for ; Fri, 9 Feb 2007 13:49:18 +0100 Date: Fri, 9 Feb 2007 13:49:18 +0100 (MET) From: Jan Engelhardt To: xfs@oss.sgi.com Subject: Inodes disappearing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10627 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 1760 Lines: 42 Hello list, here's an interesting phenomena I am seeing: # df -h /dev/hda3 215G 152G 63G 71% /sam224 /dev/dm-0 233G 233G 350M 100% /sam250 # df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda3 112254144 33076 112221068 1% /sam224 /dev/dm-0 1466272 35982 1430290 3% /sam250 How come that dm-0 has much less inodes despite the two volumes having about the same size? It can't be because of isize=512, can it? (If at all, I would expect an isize=512 volume to have less inodes than a isize=256 one for the same number of blocks.) # xfs_info /dev/dm-0 meta-data=/dev/disk/by-label/sam250 isize=256 agcount=16, agsize=3813429 blks = sectsz=512 attr=0 data = bsize=4096 blocks=61014864, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=29792, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # xfs_info /dev/hda3 meta-data=/dev/disk/by-label/sam224 isize=512 agcount=16, agsize=3507943 blks = sectsz=512 attr=0 data = bsize=4096 blocks=56127088, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=27405, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Jan -- ft: http://freshmeat.net/p/chaostables/ From owner-xfs@oss.sgi.com Fri Feb 9 07:07:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Feb 2007 07:07:55 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l19F7km7024362 for ; Fri, 9 Feb 2007 07:07:47 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 339981805FF93; Fri, 9 Feb 2007 09:07:44 -0600 (CST) Message-ID: <45CC8E3E.6090109@sandeen.net> Date: Fri, 09 Feb 2007 09:07:42 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Jan Engelhardt CC: xfs@oss.sgi.com Subject: Re: Inodes disappearing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10628 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 3394 Lines: 85 Jan Engelhardt wrote: > Hello list, > > > here's an interesting phenomena I am seeing: > > # df -h > /dev/hda3 215G 152G 63G 71% /sam224 > /dev/dm-0 233G 233G 350M 100% /sam250 > # df -i > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/hda3 112254144 33076 112221068 1% /sam224 > /dev/dm-0 1466272 35982 1430290 3% /sam250 > > How come that dm-0 has much less inodes despite the two volumes having > about the same size? It can't be because of isize=512, can it? (If at > all, I would expect an isize=512 volume to have less inodes than a > isize=256 one for the same number of blocks.) xfs dynamically allocates inodes, up to a maximum percentage of disk space specified at mkfs time, changeable by growfs. By default this is 25%, and from output below that's what you have. So the total inodes number from df is given by taking 25% of your data space, and calculating how many inodes would fit into that space. Since your filesystems are roughly the same size, that means you started out with roughly the same amount of space available for inodes in each. dm-0 has 256-byte inodes, hda3 has 512-byte inodes, which means for a given amount of space, you -can- fit more (256-byte) inodes into the filesystem on dm-0. However, dm-0 is completely full, and there is very little space left for at all. If you look at xfs_statvfs(); you'll see all these calculations that go into your answers above. inodes which -could- be created based on free space: fakeinos = statp->f_bfree << sbp->sb_inopblog; total inodes is min of (current + possible) and max inode nr: statp->f_files = MIN(sbp->sb_icount + fakeinos, (__uint64_t)XFS_MAXINUMBER); ... which is then limited by the configured max percentage: if (mp->m_maxicount) .... statp->f_files = min_t(typeof(statp->f_files), statp->f_files, mp->m_maxicount); your free blocks is low, so you start with a low number for "fakeinos" and your final result reflects that. You've used most of your potential inode space for data. -Eric > > # xfs_info /dev/dm-0 > meta-data=/dev/disk/by-label/sam250 isize=256 agcount=16, agsize=3813429 blks = sectsz=512 attr=0 > data = bsize=4096 blocks=61014864, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=29792, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > # xfs_info /dev/hda3 > meta-data=/dev/disk/by-label/sam224 isize=512 agcount=16, agsize=3507943 blks = sectsz=512 attr=0 > data = bsize=4096 blocks=56127088, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=27405, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > > Jan From owner-xfs@oss.sgi.com Sat Feb 10 01:01:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 10 Feb 2007 01:01:39 -0800 (PST) X-Spam-oss-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1A91Sm7011517 for ; Sat, 10 Feb 2007 01:01:31 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA20132; Sat, 10 Feb 2007 19:38:15 +1100 Date: Sat, 10 Feb 2007 19:38:19 +1100 From: Timothy Shimmin To: torvalds@osdl.org cc: akpm@osdl.org, xfs@oss.sgi.com Subject: XFS update for 2.6.21 Message-ID: <7AEB816692A232CFB60A832C@timothy-shimmins-power-mac-g5.local> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 10630 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 24584 Lines: 668 Hi Linus, Please pull from: git://oss.sgi.com:8090/xfs/xfs-2.6 This will update the following files: fs/xfs/linux-2.6/mrlock.h | 6 - fs/xfs/linux-2.6/xfs_aops.c | 15 +- fs/xfs/linux-2.6/xfs_buf.c | 142 ++++++++++---------- fs/xfs/linux-2.6/xfs_buf.h | 4 - fs/xfs/linux-2.6/xfs_export.c | 2 fs/xfs/linux-2.6/xfs_file.c | 4 - fs/xfs/linux-2.6/xfs_ioctl.c | 51 +++---- fs/xfs/linux-2.6/xfs_iops.c | 6 - fs/xfs/linux-2.6/xfs_lrw.c | 48 +++---- fs/xfs/linux-2.6/xfs_lrw.h | 2 fs/xfs/linux-2.6/xfs_super.c | 33 +++-- fs/xfs/linux-2.6/xfs_sysctl.c | 266 ++++++++++++++++++++++++++----------- fs/xfs/linux-2.6/xfs_vfs.h | 2 fs/xfs/linux-2.6/xfs_vnode.c | 2 fs/xfs/linux-2.6/xfs_vnode.h | 4 - fs/xfs/quota/xfs_dquot.c | 4 - fs/xfs/quota/xfs_dquot_item.c | 8 - fs/xfs/quota/xfs_qm.c | 8 - fs/xfs/quota/xfs_qm_bhv.c | 4 - fs/xfs/quota/xfs_qm_stats.c | 2 fs/xfs/quota/xfs_qm_syscalls.c | 4 - fs/xfs/quota/xfs_trans_dquot.c | 2 fs/xfs/support/debug.c | 23 ++- fs/xfs/support/debug.h | 30 ++++ fs/xfs/support/move.h | 4 - fs/xfs/xfs_acl.c | 1 fs/xfs/xfs_alloc_btree.h | 10 - fs/xfs/xfs_attr.c | 49 +++---- fs/xfs/xfs_attr_leaf.c | 54 +++++++- fs/xfs/xfs_bit.c | 2 fs/xfs/xfs_bmap.c | 101 ++++---------- fs/xfs/xfs_bmap.h | 1 fs/xfs/xfs_bmap_btree.c | 86 +----------- fs/xfs/xfs_bmap_btree.h | 59 ++------ fs/xfs/xfs_btree.h | 6 - fs/xfs/xfs_buf_item.c | 2 fs/xfs/xfs_buf_item.h | 18 --- fs/xfs/xfs_cap.h | 70 ---------- fs/xfs/xfs_da_btree.c | 18 --- fs/xfs/xfs_da_btree.h | 1 fs/xfs/xfs_dfrag.c | 1 fs/xfs/xfs_error.c | 26 ---- fs/xfs/xfs_error.h | 3 fs/xfs/xfs_extfree_item.c | 4 - fs/xfs/xfs_fsops.c | 60 +++++++- fs/xfs/xfs_ialloc.c | 2 fs/xfs/xfs_ialloc_btree.h | 10 + fs/xfs/xfs_inode.c | 30 +++- fs/xfs/xfs_inode_item.c | 2 fs/xfs/xfs_iomap.c | 10 - fs/xfs/xfs_log_recover.c | 61 +------- fs/xfs/xfs_mac.h | 106 --------------- fs/xfs/xfs_mount.c | 288 ++++++++++++++++++++++++---------------- fs/xfs/xfs_mount.h | 39 ++++- fs/xfs/xfs_rename.c | 2 fs/xfs/xfs_rtalloc.c | 110 --------------- fs/xfs/xfs_rtalloc.h | 18 --- fs/xfs/xfs_rw.c | 1 fs/xfs/xfs_trans.c | 32 ++-- fs/xfs/xfs_trans.h | 46 +++--- fs/xfs/xfs_trans_ail.c | 2 fs/xfs/xfs_vfsops.c | 45 ++++-- fs/xfs/xfs_vnodeops.c | 22 +-- 63 files changed, 885 insertions(+), 1189 deletions(-) through these commits: commit e7ff6aed8761b2c86cd9ab7083e512de2b8cfa48 Author: David Chinner Date: Sat Feb 10 18:37:46 2007 +1100 [XFS] Don't use kmap in xfs_iozero. kmap() is inefficient and does not scale well. kmap_atomic() is a better choice. Use the generic wrapper function instead of open coding the kmap-memset-dcache flush-kunmap stuff. SGI-PV: 960904 SGI-Modid: xfs-linux-melb:xfs-kern:28041a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit 6be145bfb1ce93b2dbb854fee66fbb8d04916339 Author: Eric Sandeen Date: Sat Feb 10 18:37:40 2007 +1100 [XFS] Remove a bunch of unused functions from XFS. Patch provided by Eric Sandeen (sandeen@sandeen.net). SGI-PV: 960897 SGI-Modid: xfs-linux-melb:xfs-kern:28038a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 2c36ddeda7f04c085d9a612cf8dab5f0a1cd5224 Author: Eric Sandeen Date: Sat Feb 10 18:37:33 2007 +1100 [XFS] Remove unused arguments from the XFS_BTREE_*_ADDR macros. It makes it incrementally clearer to read the code when the top of a macro spaghetti-pile only receives the 3 arguments it uses, rather than 2 extra ones which are not used. Also when you start pulling this thread out of the sweater (i.e. remove unused args from XFS_BTREE_*_ADDR), a couple other third arms etc fall off too. If they're not used in the macro, then they sometimes don't need to be passed to the function calling the macro either, etc.... Patch provided by Eric Sandeen (sandeen@sandeen.net). SGI-PV: 960197 SGI-Modid: xfs-linux-melb:xfs-kern:28037a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 7bc5306d74922d9b14f507e1164d8dd852a98ad3 Author: Eric Sandeen Date: Sat Feb 10 18:37:28 2007 +1100 [XFS] Remove unused header files for MAC and CAP checking functionality. xfs_mac.h and xfs_cap.h provide definitions and macros that aren't used anywhere in XFS at all. They are left-overs from "to be implement at some point in the future" functionality that Irix XFS has. If this functionality ever goes into Linux, it will be provided at a different layer, most likely through the security hooks in the kernel so we will never need this functionality in XFS. Patch provided by Eric Sandeen (sandeen@sandeen.net). SGI-PV: 960895 SGI-Modid: xfs-linux-melb:xfs-kern:28036a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 3c0dc77b42cee99c71e913765073888620d442fa Author: David Chinner Date: Sat Feb 10 18:37:22 2007 +1100 [XFS] Make freeze code a little cleaner. Fixes a few small issues (mostly cosmetic) that were picked up during the review cycle for the last set of freeze path changes. SGI-PV: 959267 SGI-Modid: xfs-linux-melb:xfs-kern:28035a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit f7c99b6fc7b3791cd24e0763cd4967d744c164a3 Author: Eric Sandeen Date: Sat Feb 10 18:37:16 2007 +1100 [XFS] Remove unused argument to xfs_bmap_finish The firstblock argument to xfs_bmap_finish is not used by that function. Remove it and cleanup the code a bit. Patch provided by Eric Sandeen. SGI-PV: 960196 SGI-Modid: xfs-linux-melb:xfs-kern:28034a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 39058a0e12a8b2dcb8f9345ecad52dbcfc120ef7 Author: Eric Sandeen Date: Sat Feb 10 18:37:10 2007 +1100 [XFS] Clean up use of VFS attr flags Use the the generic VFS attr flags where appropriate instead of open coding them to the same values. Patch provided by Eric Sandeen. SGI-PV: 960868 SGI-Modid: xfs-linux-melb:xfs-kern:28033a Signed-off-by: Eric Sandeen Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit 4cf3b52080b3d354b10b8b1c9147bf88118b8eef Author: Ralf Baechle Date: Sat Feb 10 18:37:04 2007 +1100 [XFS] Remove useless memory barrier wake_up's implementation does an implicit memory barrier so the explicit memory barrier is not needed in vfs_sync_worker. Patch provided by Ralf Baechle. SGI-PV: 960867 SGI-Modid: xfs-linux-melb:xfs-kern:28032a Signed-off-by: Ralf Baechle Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 3a68cbfe0277fb73d5f0c2a433884745fb500c38 Author: Eric W. Biederman Date: Sat Feb 10 18:36:59 2007 +1100 [XFS] XFS sysctl cleanups Removes unneeded sysctl insert at head behaviour. Cleans up sysctl definitions to use C99 initialisers. Patch provided by Eric W. Biederman. SGI-PV: 960192 SGI-Modid: xfs-linux-melb:xfs-kern:28031a Signed-off-by: Eric W. Biederman Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit c167b77d5e172a2deb058be442ca652ad3a417f9 Author: Lachlan McIlroy Date: Sat Feb 10 18:36:53 2007 +1100 [XFS] Fix assertion in xfs_attr_shortform_remove(). SGI-PV: 960791 SGI-Modid: xfs-linux-melb:xfs-kern:28021a Signed-off-by: Lachlan McIlroy Signed-off-by: Barry Naujok Signed-off-by: Tim Shimmin commit 681601613759accffd8e8ddbc6f942eba7ecbfe5 Author: Lachlan McIlroy Date: Sat Feb 10 18:36:47 2007 +1100 [XFS] Fix callers of xfs_iozero() to zero the correct range. The problem is the two callers of xfs_iozero() are rounding out the range to be zeroed to the end of a fsb and in some cases this extends past the new eof. The call to commit_write() in xfs_iozero() will cause the Linux inode's file size to be set too high. SGI-PV: 960788 SGI-Modid: xfs-linux-melb:xfs-kern:28013a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit 2823945fda94e0636be573a037c45cb7b6495af2 Author: David Chinner Date: Sat Feb 10 18:36:40 2007 +1100 [XFS] Ensure a frozen filesystem has a clean log before writing the dummy record. The current Linux XFS freeze code is a mess. We flush the metadata buffers out while we are still allowing new transactions to start and then fail to flush the dirty buffers back out before writing the unmount and dummy records to the log. This leads to problems when the frozen filesystem is used for snapshots - we do log recovery on a readonly image and often it appears that the log image in the snapshot is not correct. Hence we end up with hangs, oops and mount failures when trying to mount a snapshot image that has been created when the filesystem has not been correctly frozen. To fix this, we need to move th metadata flush to after we wait for all current transactions to complete in teh second stage of the freeze. This means that when we write the final log records, the log should be clean and recovery should never occur on a snapshot image created from a frozen filesystem. SGI-PV: 959267 SGI-Modid: xfs-linux-melb:xfs-kern:28010a Signed-off-by: David Chinner Signed-off-by: Donald Douwsma Signed-off-by: Tim Shimmin commit 549054afadae44889c0b40d4c3bfb0207b98d5a0 Author: David Chinner Date: Sat Feb 10 18:36:35 2007 +1100 [XFS] Fix sub-block zeroing for buffered writes into unwritten extents. When writing less than a filesystem block of data into an unwritten extent via buffered I/O, __xfs_get_blocks fails to set the buffer new flag. As a result, the generic code will not zero either edge of the block resulting in garbage being written to disk either side of the real data. Set the buffer new state on bufferd writes to unwritten extents to ensure that zeroing occurs. SGI-PV: 960328 SGI-Modid: xfs-linux-melb:xfs-kern:28000a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit 5478eead8528f6cb5ebe3015fb88b68b175e1093 Author: Lachlan McIlroy Date: Sat Feb 10 18:36:29 2007 +1100 [XFS] Re-initialize the per-cpu superblock counters after recovery. After filesystem recovery the superblock is re-read to bring in any changes. If the per-cpu superblock counters are not re-initialized from the superblock then the next time the per-cpu counters are disabled they might overwrite the global counter with a bogus value. SGI-PV: 957348 SGI-Modid: xfs-linux-melb:xfs-kern:27999a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit c97be736051dacefb00643095d76fd5b70dfef7b Author: Kevin Jamieson Date: Sat Feb 10 18:36:23 2007 +1100 [XFS] Fix block reservation changes for non-SMP systems. SGI-PV: 956323 SGI-Modid: xfs-linux-melb:xfs-kern:27940a Signed-off-by: Kevin Jamieson Signed-off-by: David Chatterton Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit dbcabad19aa91dc9bc7176fd2853fa74f724cd2f Author: David Chinner Date: Sat Feb 10 18:36:17 2007 +1100 [XFS] Fix block reservation mechanism. The block reservation mechanism has been broken since the per-cpu superblock counters were introduced. Make the block reservation code work with the per-cpu counters by syncing the counters, snapshotting the amount of available space and then doing a modifcation of the counter state according to the result. Continue in a loop until we either have no space available or we reserve some space. SGI-PV: 956323 SGI-Modid: xfs-linux-melb:xfs-kern:27895a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit 20f4ebf2bf2f57c1a9abb3655391336cc90314b3 Author: David Chinner Date: Sat Feb 10 18:36:10 2007 +1100 [XFS] Make growfs work for amounts greater than 2TB The free block modification code has a 32bit interface, limiting the size the filesystem can be grown even on 64 bit machines. On 32 bit machines, there are other 32bit variables in transaction structures and interfaces that need to be expanded to allow this to work. SGI-PV: 959978 SGI-Modid: xfs-linux-melb:xfs-kern:27894a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit f74eaf59b36c0ad01f416b567f89c737bbf82bae Author: David Chinner Date: Sat Feb 10 18:36:04 2007 +1100 [XFS] Fix inode log item use-after-free on forced shutdown SGI-PV: 959388 SGI-Modid: xfs-linux-melb:xfs-kern:27805a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit e5889e90dda328443161e9512f1123c9814d03de Author: Barry Naujok Date: Sat Feb 10 18:35:58 2007 +1100 [XFS] Fix attr2 corruption with btree data extents SGI-PV: 958747 SGI-Modid: xfs-linux-melb:xfs-kern:27792a Signed-off-by: Barry Naujok Signed-off-by: Russell Cattelan Signed-off-by: Tim Shimmin commit 7666ab5fb378678a9d5eb3c0dc8d3170e274e7a4 Author: Vlad Apostolov Date: Sat Feb 10 18:35:52 2007 +1100 [XFS] Workaround log space issue by increasing XFS_TRANS_PUSH_AIL_RESTARTS SGI-PV: 959264 SGI-Modid: xfs-linux-melb:xfs-kern:27750a Signed-off-by: Vlad Apostolov Signed-off-by: David Chatterton Signed-off-by: Tim Shimmin commit 5180602e6fd6f7d221e51670567f3809ecfe968f Author: Lachlan McIlroy Date: Sat Feb 10 18:35:46 2007 +1100 [XFS] remove unused filp from ioctl functions SGI-PV: 959140 SGI-Modid: xfs-linux-melb:xfs-kern:27712a Signed-off-by: Lachlan McIlroy Signed-off-by: Eric Sandeen Signed-off-by: Tim Shimmin commit a3227fb99675ebcdbe89e6954a85742c0dd11f0a Author: Lachlan McIlroy Date: Sat Feb 10 18:35:40 2007 +1100 [XFS] mraccessf & mrupdatef are supposed to be the "flags" versions of the functions, but they a) ignore the flags parameter completely, and b) are never called directly, only via the flag-less defines anyway So, drop the #define indirection, and rename mraccessf to mraccess, etc. SGI-PV: 959138 SGI-Modid: xfs-linux-melb:xfs-kern:27711a Signed-off-by: Lachlan McIlroy Signed-off-by: Eric Sandeen Signed-off-by: Tim Shimmin commit 1f9b3b64d417a714eb79d9a4cd4927ab304b0fc0 Author: Lachlan McIlroy Date: Sat Feb 10 18:35:33 2007 +1100 [XFS] remove unused xflags parameter from sync routines SGI-PV: 959137 SGI-Modid: xfs-linux-melb:xfs-kern:27710a Signed-off-by: Lachlan McIlroy Signed-off-by: Eric Sandeen Signed-off-by: Tim Shimmin commit 1c91ad3aedba82a64ae06a5a0a5651105d378112 Author: Lachlan McIlroy Date: Sat Feb 10 18:35:27 2007 +1100 [XFS] fix sparse warning in xfs_da_btree.c SGI-PV: 954580 SGI-Modid: xfs-linux-melb:xfs-kern:27702a Signed-off-by: Lachlan McIlroy Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit e5eb7f202b7a1a2d20a0b9866805314bf6464fd0 Author: Lachlan McIlroy Date: Sat Feb 10 18:35:21 2007 +1100 [XFS] use struct kvec in struct uio SGI-PV: 954580 SGI-Modid: xfs-linux-melb:xfs-kern:27701a Signed-off-by: Lachlan McIlroy Signed-off-by: Christoph Hellwig Signed-off-by: Tim Shimmin commit 03135cf72621fccab57728f0ba3ab5a551df1cc1 Author: David Chinner Date: Sat Feb 10 18:35:15 2007 +1100 [XFS] Fix UP build breakage due to undefined m_icsb_mutex. SGI-PV: 952227 SGI-Modid: xfs-linux-melb:xfs-kern:27692a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit 20b642858b6bb413976ff13ae6a35cc596967bab Author: David Chinner Date: Sat Feb 10 18:35:09 2007 +1100 [XFS] Reduction global superblock lock contention near ENOSPC. The existing per-cpu superblock counter code uses the global superblock spin lock when we approach ENOSPC for global synchronisation. On larger machines than this code was originally tested on this can still get catastrophic spinlock contention due increasing rebalance frequency near ENOSPC. By introducing a sleeping lock that is used to serialise balances and modifications near ENOSPC we prevent contention from needlessly from wasting the CPU time of potentially hundreds of CPUs. To reduce the number of balances occuring, we separate the need rebalance case from the slow allocate case. Now, a counter running dry will trigger a rebalance during which counters are disabled. Any thread that sees a disabled counter enters a different path where it waits on the new mutex. When it gets the new mutex, it checks if the counter is disabled. If the counter is disabled, then we _know_ that we have to use the global counter and lock and it is safe to do so immediately. Otherwise, we drop the mutex and go back to trying the per-cpu counters which we know were re-enabled. SGI-PV: 952227 SGI-Modid: xfs-linux-melb:xfs-kern:27612a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy Signed-off-by: Tim Shimmin commit 804195b63a6dcb767f5fae43b435067079b52903 Author: Eric Sandeen Date: Sat Feb 10 18:35:02 2007 +1100 [XFS] Get rid of old 5.3/6.1 v1 log items. Cleanup patch sent in by Eric Sandeen. SGI-PV: 958736 SGI-Modid: xfs-linux-melb:xfs-kern:27596a Signed-off-by: Eric Sandeen Signed-off-by: Tim Shimmin commit 7989cb8ef5dbc1411d3be48218c7b25ef6e71699 Author: David Chinner Date: Sat Feb 10 18:34:56 2007 +1100 [XFS] Keep stack usage down for 4k stacks by using noinline. gcc-4.1 and more recent aggressively inline static functions which increases XFS stack usage by ~15% in critical paths. Prevent this from occurring by adding noinline to the STATIC definition. Also uninline some functions that are too large to be inlined and were causing problems with CONFIG_FORCED_INLINING=y. Finally, clean up all the different users of inline, __inline and __inline__ and put them under one STATIC_INLINE macro. For debug kernels the STATIC_INLINE macro uninlines those functions. SGI-PV: 957159 SGI-Modid: xfs-linux-melb:xfs-kern:27585a Signed-off-by: David Chinner Signed-off-by: David Chatterton Signed-off-by: Tim Shimmin commit 5e6a07dfe404cd4d8494d842b54706cb007fa04b Author: David Chinner Date: Sat Feb 10 18:34:49 2007 +1100 [XFS] Current usage of buftarg flags is incorrect. The {test,set,clear}_bit() operations take a bit index for the bit to operate on. The XBT_* flags are defined as bit fields which is incorrect, not to mention the way the bit fields are enumerated is broken too. This was only working by chance. Fix the definitions of the flags and make the code using them use the {test,set,clear}_bit() operations correctly. SGI-PV: 958639 SGI-Modid: xfs-linux-melb:xfs-kern:27565a Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit dc74eaad8cda9f12a885639b4f2513c99e9b483a Author: Lachlan McIlroy Date: Sat Feb 10 18:34:38 2007 +1100 [XFS] Prevent buffer overrun in cmn_err(). The message buffer used by cmn_err() is only 256 bytes and some CXFS messages were exceeding this length. Since we were using vsprintf() and not checking for buffer overruns we were clobbering memory beyond the buffer. The size of the buffer has been increased to 1024 bytes so we can capture these larger messages and we are now using vsnprintf() to prevent overrunning the buffer size. SGI-PV: 958599 SGI-Modid: xfs-linux-melb:xfs-kern:27561a Signed-off-by: Lachlan McIlroy Signed-off-by: Geoffrey Wehrman Signed-off-by: Tim Shimmin commit 585e6d8856526a846b90b485abf37ec40e5da1cf Author: David Chinner Date: Sat Feb 10 18:32:29 2007 +1100 [XFS] Fix a synchronous buftarg flush deadlock when freezing. At the last stage of a freeze, we flush the buftarg synchronously over and over again until it succeeds twice without skipping any buffers. The delwri list flush skips pinned buffers, but tries to flush all others. It removes the buffers from the delwri list, then tries to lock them one at a time as it traverses the list to issue the I/O. It holds them locked until we issue all of the I/O and then unlocks them once we've waited for it to complete. The problem is that during a freeze, the filesystem may still be doing stuff - like flushing delalloc data buffers - in the background and hence we can be trying to lock buffers that were on the delwri list at the same time. Hence we can get ABBA deadlocks between threads doing allocation and the buftarg flush (freeze) thread. Fix it by skipping locked (and pinned) buffers as we traverse the delwri buffer list. SGI-PV: 957195 SGI-Modid: xfs-linux-melb:xfs-kern:27535a Signed-off-by: David Chinner Signed-off-by: Tim Shimmin commit dac61f521b1e4d2c6c48023f2f2743c6096b48ca Author: David Chinner Date: Sat Feb 10 18:27:56 2007 +1100 [XFS] Make quiet mounts quiet The XFS quiet mount logic was inverted making quiet mounts noisy and vice versa. Fix it. SGI-PV: 958469 SGI-Modid: xfs-linux-melb:xfs-kern:27520a Signed-off-by: David Chinner Signed-off-by: Eric Sandeen Signed-off-by: Tim Shimmin From owner-xfs@oss.sgi.com Mon Feb 12 21:52:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 12 Feb 2007 21:52:20 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1D5qAm7031781 for ; Mon, 12 Feb 2007 21:52:13 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA25884; Tue, 13 Feb 2007 16:52:05 +1100 Message-ID: <45D152C1.4080801@sgi.com> Date: Tue, 13 Feb 2007 16:55:13 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE - 960928: dmapi destroy events not generated for removing files without attributes set Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10633 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 575 Lines: 16 Date: Tue Feb 13 16:48:40 AEDT 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: vapo, tes Author: Christopher Pascoe The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: linux-melb:dmapi:28087a fs/dmapi/dmapi_event.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dmapi/dmapi_event.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h - patch author: Christopher Pascoe. dmapi destroy events not generated for removing files without attributes set From owner-xfs@oss.sgi.com Mon Feb 12 22:41:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 12 Feb 2007 22:41:14 -0800 (PST) X-Spam-oss-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50, MIME_QP_LONG_LINE autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1D6f2m7004649 for ; Mon, 12 Feb 2007 22:41:04 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA27208 for ; Tue, 13 Feb 2007 17:41:00 +1100 Message-Id: <200702130641.RAA27208@larry.melbourne.sgi.com> From: "Barry Naujok" To: Subject: [PATCH] XFS metadata dump feature added to xfs_db Date: Tue, 13 Feb 2007 17:44:07 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_008F_01C74F96.8FAF0850" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdPOlwRzUFCofFrRDCRRgT+1aQrdA== X-archive-position: 10634 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 36942 Lines: 1424 This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C74F96.8FAF0850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The attached patch adds a metadata dump and restore command to xfs_db. A script is also supplied called xfs_metadata to make it simpler to generate a metadump file from the command line. The purpose of this feature is to allow a user with a corrupted and/or unrepairable filesystem to generate a compact metadata only image that is small and compressable that can easily be transferred to us for analysis. The command also supports output to stdout, so can be used in the following fashion: # xfs_metadump /dev/foo - | bzip2 > /tmp/foo.bz2 A man page update for xfs_db and a new man page for xfs_metadump will be created before this is checked in. I will also investigate a "name obfuscation" option that works with the hash entries in directories and extended attributes. This would be a future enhancement that won't make this patch. Regards, Barry. ------=_NextPart_000_008F_01C74F96.8FAF0850 Content-Type: application/octet-stream; name="xfs_metadump.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xfs_metadump.patch" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xfsprogs/db/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- a/xfsprogs/db/Makefile 2007-02-13 17:29:33.000000000 +1100 +++ b/xfsprogs/db/Makefile 2007-02-13 11:24:54.820768218 +1100 @@ -11,11 +11,11 @@ HFILES =3D addr.h agf.h agfl.h agi.h attr. bmapbt.h bmroot.h bnobt.h check.h cntbt.h command.h convert.h \ dbread.h debug.h dir.h dir2.h dir2sf.h dirshort.h dquot.h echo.h \ faddr.h field.h flist.h fprint.h frag.h freesp.h hash.h help.h \ - init.h inobt.h inode.h input.h io.h malloc.h output.h \ + init.h inobt.h inode.h input.h io.h malloc.h metadump.h output.h \ print.h quit.h sb.h sig.h strvec.h text.h type.h write.h \ attrset.h CFILES =3D $(HFILES:.h=3D.c) -LSRCFILES =3D xfs_admin.sh xfs_check.sh xfs_ncheck.sh +LSRCFILES =3D xfs_admin.sh xfs_check.sh xfs_ncheck.sh xfs_metadump.sh LLDLIBS =3D $(LIBXFS) $(LIBXLOG) $(LIBUUID) $(LIBRT) LTDEPENDENCIES =3D $(LIBXFS) $(LIBXLOG) LLDFLAGS +=3D -static @@ -40,4 +40,5 @@ install: default $(INSTALL) -m 755 xfs_admin.sh $(PKG_BIN_DIR)/xfs_admin $(INSTALL) -m 755 xfs_check.sh $(PKG_BIN_DIR)/xfs_check $(INSTALL) -m 755 xfs_ncheck.sh $(PKG_BIN_DIR)/xfs_ncheck + $(INSTALL) -m 755 xfs_metadump.sh $(PKG_BIN_DIR)/xfs_metadump install-dev: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xfsprogs/db/command.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=3D=3D=3D=3D=3D=3D=3D=3D --- a/xfsprogs/db/command.c 2007-02-13 17:29:33.000000000 +1100 +++ b/xfsprogs/db/command.c 2007-01-30 15:11:45.903970466 +1100 @@ -131,6 +131,7 @@ init_commands(void) inode_init(); input_init(); io_init(); + metadump_init(); output_init(); print_init(); quit_init(); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xfsprogs/db/init.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=3D=3D=3D=3D=3D=3D=3D=3D --- a/xfsprogs/db/init.c 2007-02-13 17:29:33.000000000 +1100 +++ b/xfsprogs/db/init.c 2007-02-13 16:19:42.359432895 +1100 @@ -107,8 +107,8 @@ init( } =20 if (read_bbs(XFS_SB_DADDR, 1, &bufp, NULL)) { - dbprintf(_("%s: %s is invalid (cannot read first 512 bytes)\n"), - progname, fsdevice); + fprintf(stderr, _("%s: %s is invalid (cannot read first 512 " + "bytes)\n"), progname, fsdevice); exit(1); } =20 @@ -118,7 +118,7 @@ init( =20 sbp =3D &xmount.m_sb; if (sbp->sb_magicnum !=3D XFS_SB_MAGIC) { - dbprintf(_("%s: unexpected XFS SB magic number 0x%08x\n"), + fprintf(stderr, _("%s: unexpected XFS SB magic number 0x%08x\n"), progname, sbp->sb_magicnum); } =20 @@ -128,8 +128,8 @@ init( mp =3D libxfs_mount(&xmount, sbp, x.ddev, x.logdev, x.rtdev, LIBXFS_MOUNT_DEBUGGER); if (!mp) { - dbprintf(_("%s: device %s unusable (not an XFS filesystem?)\n"), - progname, fsdevice); + fprintf(stderr, _("%s: device %s unusable (not an XFS " + "filesystem?)\n"), progname, fsdevice); exit(1); } } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xfsprogs/db/metadump.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=3D=3D=3D=3D=3D=3D=3D=3D --- a/xfsprogs/db/metadump.c 2007-02-13 17:29:33.000000000 +1100 +++ b/xfsprogs/db/metadump.c 2007-02-13 16:15:18.160445693 +1100 @@ -0,0 +1,1195 @@ +/* + * 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 + */ + +#include +#include "bmap.h" +#include "command.h" +#include "metadump.h" +#include "io.h" +#include "output.h" +#include "type.h" +#include "init.h" +#include "sig.h" + +/* copy all metadata structures to/from a file */ + +static int metadump_f(int argc, char **argv); +static int metarestore_f(int argc, char **argv); +static void metadump_help(void); + +#define XFS_MD_MAGIC 0x5846534d /* 'XFSM' */ + +/* + * metadump commands issue info/wornings/errors to standard error as + * metadump supports stdout as a destination (and from stdin for restore). + * + * All static functions return zero on failure, while the public functions + * return zero on success. + */ + +static const cmdinfo_t metadump_cmd =3D + { "metadump", NULL, metadump_f, 0, -1, 0, + "[-e] [-g] [-w] filename", + "dump metadata to a file", metadump_help }; + +static const cmdinfo_t metarestore_cmd =3D + { "metarestore", NULL, metarestore_f, 0, -1, 0, + "[-g] filename", + "restore metadata from a file", NULL }; + +typedef struct xfs_metablock { + __be32 mb_magic; + __be16 mb_count; + __uint8_t mb_blocklog; + __uint8_t mb_reserved; + /* followed by an array of xfs_daddr_t */ +} xfs_metablock_t; + +static int fd; /* metadump file */ + +static xfs_metablock_t *metablock; /* header + index + buffers */ +static __be64 *block_index; +static char *block_buffer; + +static int num_indicies; +static int cur_index; + +static int show_progress =3D 0; +static int stop_on_read_error =3D 0; +static int wflag =3D 0; +static int progress_since_warning =3D 0; + +void +metadump_init(void) +{ + add_command(&metadump_cmd); + if (expert_mode) + add_command(&metarestore_cmd); +} + +static void +metadump_help(void) +{ + dbprintf( +"\n" +" The 'metadump' command dumps the known metadata to a compact file suitab= le\n" +" for compressing and sending to an XFS maintainer for corruption analysis= \n" +" or xfs_repair failures.\n\n" +" There are 3 options:\n" +" -e -- Ignore read errors and keep going\n" +" -g -- Display dump progress\n" +" -w -- Show warnings of bad metadata information\n" +"\n"); +} + +static void +print_warning(const char *fmt, ...) +{ + char buf[200]; + va_list ap; + + if (seenint()) + return; + + va_start(ap, fmt); + vsnprintf(buf, sizeof(buf), fmt, ap); + va_end(ap); + buf[sizeof(buf)-1] =3D '\0'; + + fprintf(stderr, "%s%s: %s\n", progress_since_warning ? "\n" : "", + progname, buf); + progress_since_warning =3D 0; +} + +static void +print_progress(const char *fmt, ...) +{ + char buf[60]; + va_list ap; + FILE *f; + + if (seenint()) + return; + + va_start(ap, fmt); + vsnprintf(buf, sizeof(buf), fmt, ap); + va_end(ap); + buf[sizeof(buf)-1] =3D '\0'; + + f =3D (fd =3D=3D STDOUT_FILENO) ? stderr : stdout; + fprintf(f, "\r%-59s", buf); + fflush(f); + progress_since_warning =3D 1; +} + +/* + * A complete dump file will have a "zero" entry in the last index block, + * even if the dump is exactly aligned, the last index will be full of + * zeros. If the last index entry is non-zero, the dump is incomplete. + * Correspondingly, the last chunk will have a count < num_indicies. + */ + +static int +write_index(void) +{ + /* + * write index block and following data blocks (streaming) + */ + metablock->mb_count =3D cpu_to_be16(cur_index); + if (write(fd, metablock, (cur_index + 1) << BBSHIFT) =3D=3D -1) { + print_warning("error writing to file: %s", strerror(errno)); + return 0; + } + + memset(block_index, 0, num_indicies * sizeof(__be64)); + cur_index =3D 0; + return 1; +} + +static int +write_buf( + iocur_t *buf) +{ + char *data; + __int64_t off; + int i; + + for (i =3D 0, off =3D buf->bb, data =3D buf->data; + i < buf->blen; + i++, off++, data +=3D BBSIZE) { + block_index[cur_index] =3D cpu_to_be64(off); + memcpy(&block_buffer[cur_index << BBSHIFT], data, BBSIZE); + if (++cur_index =3D=3D num_indicies) { + if (!write_index()) + return 0; + } + } + return !seenint(); +} + + +static int +scan_btree( + xfs_agnumber_t agno, + xfs_agblock_t agbno, + int level, + typnm_t btype, + void *arg, + int (*func)(xfs_btree_hdr_t *bthdr, + xfs_agnumber_t agno, + xfs_agblock_t agbno, + int level, + typnm_t btype, + void *arg)) +{ + push_cur(); + set_cur(&typtab[btype], XFS_AGB_TO_DADDR(mp, agno, agbno), blkbb, + DB_RING_IGN, NULL); + if (iocur_top->data =3D=3D NULL) { + print_warning("cannot read %s block %u/%u", typtab[btype].name, + agno, agbno); + return !stop_on_read_error; + } + if (!write_buf(iocur_top)) + return 0; + + if (!(*func)(iocur_top->data, agno, agbno, level - 1, btype, arg)) + return 0; + + pop_cur(); + return 1; +} + +/* free space tree copy routines */ + +static int +valid_bno( + xfs_agblock_t bno, + xfs_agnumber_t agno, + xfs_agblock_t agbno, + typnm_t btype) +{ + if (bno > 0 && bno <=3D mp->m_sb.sb_agblocks) + return 1; + + if (wflag) + print_warning("invalid block number (%u) in %s block %u/%u", + bno, typtab[btype].name, agno, agbno); + return 0; +} + +static int +scanfunc_freesp( + xfs_btree_hdr_t *bthdr, + xfs_agnumber_t agno, + xfs_agblock_t agbno, + int level, + typnm_t btype, + void *arg) +{ + xfs_alloc_ptr_t *pp; + int i; + int nrecs; + + if (level =3D=3D 0) + return 1; + + nrecs =3D be16_to_cpu(bthdr->bb_numrecs); + if (nrecs > mp->m_alloc_mxr[1]) { + if (wflag) + print_warning("invalid nrecs (%u) in %s block %u/%u", + nrecs, typtab[btype].name, agno, agbno); + return 1; + } + + pp =3D XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_alloc, bthdr, 1, + mp->m_alloc_mxr[1]); + for (i =3D 0; i < nrecs; i++) { + if (!valid_bno(be32_to_cpu(pp[i]), agno, agbno, btype)) + continue; + if (!scan_btree(agno, be32_to_cpu(pp[i]), level, btype, arg, + scanfunc_freesp)) + return 0; + } + return 1; +} + +static int +copy_free_bno_btree( + xfs_agnumber_t agno, + xfs_agf_t *agf) +{ + xfs_agblock_t root; + int levels; + + root =3D be32_to_cpu(agf->agf_roots[XFS_BTNUM_BNO]); + levels =3D be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNO]); + + /* validate root and levels before processing the tree */ + if (root =3D=3D 0 || root > mp->m_sb.sb_agblocks) { + if (wflag) + print_warning("invalid block number (%u) in bnobt " + "root in agf %u", root, agno); + return 1; + } + if (levels >=3D XFS_BTREE_MAXLEVELS) { + if (wflag) + print_warning("invalid level (%u) in bnobt root " + "in agf %u", levels, agno); + return 1; + } + + return scan_btree(agno, root, levels, TYP_BNOBT, agf, scanfunc_freesp); +} + +static int +copy_free_cnt_btree( + xfs_agnumber_t agno, + xfs_agf_t *agf) +{ + xfs_agblock_t root; + int levels; + + root =3D be32_to_cpu(agf->agf_roots[XFS_BTNUM_CNT]); + levels =3D be32_to_cpu(agf->agf_levels[XFS_BTNUM_CNT]); + + /* validate root and levels before processing the tree */ + if (root =3D=3D 0 || root > mp->m_sb.sb_agblocks) { + if (wflag) + print_warning("invalid block number (%u) in cntbt " + "root in agf %u", root, agno); + return 1; + } + if (levels >=3D XFS_BTREE_MAXLEVELS) { + if (wflag) + print_warning("invalid level (%u) in cntbt root " + "in agf %u", levels, agno); + return 1; + } + + return scan_btree(agno, root, levels, TYP_CNTBT, agf, scanfunc_freesp); +} + +/* inode copy routines */ + +static int +process_bmbt_reclist( + xfs_bmbt_rec_t *rp, + int numrecs, + typnm_t btype) +{ + int i; + xfs_dfiloff_t o; + xfs_dfsbno_t s; + xfs_dfilblks_t c; + int f; + + if (btype =3D=3D TYP_DATA) + return 1; + + for (i =3D 0; i < numrecs; i++, rp++) { + convert_extent(rp, &o, &s, &c, &f); + + push_cur(); + set_cur(&typtab[btype], XFS_FSB_TO_DADDR(mp, s), c * blkbb, + DB_RING_IGN, NULL); + if (iocur_top->data =3D=3D NULL) { + print_warning("cannot read %s block %u/%u", + typtab[btype].name, + XFS_FSB_TO_AGNO(mp, s), + XFS_FSB_TO_AGBNO(mp, s)); + if (stop_on_read_error) + return 0; + } else { + if (!write_buf(iocur_top)) + return 0; + } + pop_cur(); + } + + return 1; +} + +static int +scanfunc_bmap( + xfs_btree_hdr_t *bthdr, + xfs_agnumber_t agno, + xfs_agblock_t agbno, + int level, + typnm_t btype, + void *arg) /* ptr to itype */ +{ + int i; + xfs_bmbt_ptr_t *pp; + xfs_bmbt_rec_t *rp; + int nrecs; + + nrecs =3D be16_to_cpu(bthdr->bb_numrecs); + + if (level =3D=3D 0) { + if (nrecs > mp->m_bmap_dmxr[0]) { + if (wflag) + print_warning("invalid numrecs (%u) in %s " + "block %u/%u", nrecs, + typtab[btype].name, agno, agbno); + return 1; + } + rp =3D XFS_BTREE_REC_ADDR(mp->m_sb.sqb_blocksize, xfs_bmbt, bthdr, + 1, mp->m_bmap_dmxr[0]); + + return process_bmbt_reclist(rp, nrecs, *(typnm_t*)arg); + } + + if (nrecs > mp->m_bmap_dmxr[1]) { + if (wflag) + print_warning("invalid numrecs (%u) in %s block %u/%u", + nrecs, typtab[btype].name, agno, agbno); + return 1; + } + pp =3D XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, bthdr, 1, + mp->m_bmap_dmxr[1]); + for (i =3D 0; i < nrecs; i++) { + xfs_agnumber_t ag; + xfs_agblock_t bno; + + ag =3D XFS_FSB_TO_AGNO(mp, be64_to_cpu(pp[i])); + bno =3D XFS_FSB_TO_AGBNO(mp, be64_to_cpu(pp[i])); + + if (bno =3D=3D 0 || bno > mp->m_sb.sb_agblocks || + ag > mp->m_sb.sb_agcount) { + if (wflag) + print_warning("invalid block number (%u/%u) " + "in %s block %u/%u", ag, bno, + typtab[btype].name, agno, agbno); + continue; + } + + if (!scan_btree(ag, bno, level, btype, arg, scanfunc_bmap)) + return 0; + } + return 1; +} + +static int +process_btinode( + xfs_ino_t ino, + xfs_dinode_t *dip, + typnm_t itype) +{ + xfs_bmdr_block_t *dib; + int i; + xfs_bmbt_ptr_t *pp; + xfs_bmbt_rec_t *rp; + int level; + int nrecs; + int maxrecs; + int whichfork; + typnm_t btype; + + whichfork =3D (itype =3D=3D TYP_ATTR) ? XFS_ATTR_FORK : XFS_DATA_FORK; + btype =3D (itype =3D=3D TYP_ATTR) ? TYP_BMAPBTA : TYP_BMAPBTD; + + dib =3D (xfs_bmdr_block_t *)XFS_DFORK_PTR(dip, whichfork); + level =3D be16_to_cpu(dib->bb_level); + nrecs =3D be16_to_cpu(dib->bb_numrecs); + + if (level > XFS_BM_MAXLEVELS(mp, whichfork)) { + if (wflag) + print_warning("invalid level (%u) in inode %lld %s " + "root", level, (long long)ino, + typtab[btype].name); + return 1; + } + + if (level =3D=3D 0) { + rp =3D XFS_BTREE_REC_ADDR(XFS_DFORK_SIZE(dip, mp, whichfork), + xfs_bmdr, dib, 1, XFS_BTREE_BLOCK_MAXRECS( + XFS_DFORK_SIZE(dip, mp, whichfork), + xfs_bmdr, 1)); + + return process_bmbt_reclist(rp, nrecs, itype); + } + + maxrecs =3D XFS_BTREE_BLOCK_MAXRECS(XFS_DFORK_SIZE(dip, mp, whichfork), + xfs_bmdr, 0); + if (nrecs > maxrecs) { + if (wflag) + print_warning("invalid numrecs (%u) in inode %lld %s " + "root", nrecs, (long long)ino, + typtab[btype].name); + return 1; + } + + pp =3D XFS_BTREE_PTR_ADDR(XFS_DFORK_SIZE(dip, mp, whichfork), xfs_bmdr, + dib, 1, maxrecs); + for (i =3D 0; i < nrecs; i++) { + xfs_agnumber_t ag; + xfs_agblock_t bno; + + ag =3D XFS_FSB_TO_AGNO(mp, be64_to_cpu(pp[i])); + bno =3D XFS_FSB_TO_AGBNO(mp, be64_to_cpu(pp[i])); + + if (bno =3D=3D 0 || bno > mp->m_sb.sb_agblocks || + ag > mp->m_sb.sb_agcount) { + if (wflag) + print_warning("invalid block number (%u/%u) " + "in inode %llu %s root", ag, + bno, (long long)ino, + typtab[btype].name); + continue; + } + + if (!scan_btree(ag, bno, level, btype, &itype, scanfunc_bmap)) + return 0; + } + return 1; +} + +static int +process_exinode( + xfs_dinode_t *dip, + typnm_t itype) +{ + int whichfork; + + whichfork =3D (itype =3D=3D TYP_ATTR) ? XFS_ATTR_FORK : XFS_DATA_FORK; + + return process_bmbt_reclist( + (xfs_bmbt_rec_t *)XFS_DFORK_PTR(dip, whichfork), + XFS_DFORK_NEXTENTS_HOST(dip, whichfork), itype); +} + +static int +process_inode_data( + xfs_ino_t ino, + xfs_dinode_t *dip, + typnm_t itype) +{ + switch (dip->di_core.di_format) { + case XFS_DINODE_FMT_EXTENTS: + return process_exinode(dip, itype); + + case XFS_DINODE_FMT_BTREE: + return process_btinode(ino, dip, itype); + } + return 1; +} + +static int +process_inode( + xfs_agnumber_t agno, + xfs_agino_t agino, + xfs_dinode_t *dip) +{ + xfs_dinode_core_t odic; + xfs_ino_t lino; + int success; + + /* convert the core */ + memcpy(&odic, &dip->di_core, sizeof(xfs_dinode_core_t)); + libxfs_xlate_dinode_core((xfs_caddr_t)&odic, &dip->di_core, 1); + + success =3D 1; + lino =3D XFS_AGINO_TO_INO(mp, agno, agino); + + /* copy appropriate data fork metadata */ + switch (dip->di_core.di_mode & S_IFMT) { + case S_IFDIR: + success =3D process_inode_data(lino, dip, TYP_DIR2); + break; + case S_IFLNK: + success =3D process_inode_data(lino, dip, TYP_SYMLINK); + break; + default: + success =3D process_inode_data(lino, dip, TYP_DATA); + } + + /* copy extended attributes if they exist */ + if (success && dip->di_core.di_forkoff) { + switch (dip->di_core.di_aformat) { + case XFS_DINODE_FMT_EXTENTS: + success =3D process_exinode(dip, TYP_ATTR); + break; + + case XFS_DINODE_FMT_BTREE: + success =3D process_btinode(lino, dip, TYP_ATTR); + break; + } + } + + /* restore the core back to it's original endianess */ + memcpy(&dip->di_core, &odic, sizeof(xfs_dinode_core_t)); + return success; +} + +static __uint32_t inodes_copied =3D 0; + +static int +copy_inode_chunk( + xfs_agnumber_t agno, + xfs_inobt_rec_t *rp) +{ + xfs_agino_t agino; + int off; + xfs_agblock_t agbno; + int i; + + agino =3D be32_to_cpu(rp->ir_startino); + agbno =3D XFS_AGINO_TO_AGBNO(mp, agino); + off =3D XFS_INO_TO_OFFSET(mp, agino); + + push_cur(); + set_cur(&typtab[TYP_INODE], XFS_AGB_TO_DADDR(mp, agno, agbno), + XFS_FSB_TO_BB(mp, XFS_IALLOC_BLOCKS(mp)), + DB_RING_IGN, NULL); + if (iocur_top->data =3D=3D NULL) { + print_warning("cannot read inode block %u/%u", agno, agbno); + return !stop_on_read_error; + } + + /* + * scan through inodes and copy any btree extent lists, directory + * contents and extended attributes. + */ + + for (i =3D 0; i < XFS_INODES_PER_CHUNK; i++) { + xfs_dinode_t *dip; + + if (XFS_INOBT_IS_FREE_DISK(rp, i)) + continue; + + dip =3D (xfs_dinode_t *)((char *)iocur_top->data + + ((off + i) << mp->m_sb.sb_inodelog)); + + if (!process_inode(agno, agino + i, dip)) + return 0; + } + + if (!write_buf(iocur_top)) + return 0; + + inodes_copied +=3D XFS_INODES_PER_CHUNK; + + if (show_progress) + print_progress("Copied %u of %u inodes (%u of %u AGs)", + inodes_copied, mp->m_sb.sb_icount, agno, + mp->m_sb.sb_agcount); + + pop_cur(); + + return 1; +} + +static int +scanfunc_ino( + xfs_btree_hdr_t *bthdr, + xfs_agnumber_t agno, + xfs_agblock_t agbno, + int level, + typnm_t btype, + void *arg) +{ + xfs_inobt_rec_t *rp; + xfs_inobt_ptr_t *pp; + int i; + + if (level =3D=3D 0) { + rp =3D XFS_BTREE_REC_ADDR(mp->m_sb.sb_blocksize, xfs_inobt, + bthdr, 1, mp->m_inobt_mxr[0]); + for (i =3D 0; i < be16_to_cpu(bthdr->bb_numrecs); i++, rp++) { + if (!copy_inode_chunk(agno, rp)) + return 0; + } + } else { + pp =3D XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_inobt, + bthdr, 1, mp->m_inobt_mxr[1]); + for (i =3D 0; i < be16_to_cpu(bthdr->bb_numrecs); i++) { + if (!valid_bno(be32_to_cpu(pp[i]), agno, agbno, btype)) + continue; + if (!scan_btree(agno, be32_to_cpu(pp[i]), level, + btype, arg, scanfunc_ino)) + return 0; + } + } + return 1; +} + +static int +copy_inodes( + xfs_agnumber_t agno, + xfs_agi_t *agi) +{ + xfs_agblock_t root; + int levels; + + root =3D be32_to_cpu(agi->agi_root); + levels =3D be32_to_cpu(agi->agi_level); + + /* validate root and levels before processing the tree */ + if (root =3D=3D 0 || root > mp->m_sb.sb_agblocks) { + if (wflag) + print_warning("invalid block number (%u) in inobt " + "root in agi %u", root, agno); + return 1; + } + if (levels >=3D XFS_BTREE_MAXLEVELS) { + if (wflag) + print_warning("invalid level (%u) in inobt root " + "in agi %u", levels, agno); + return 1; + } + + return scan_btree(agno, root, levels, TYP_INOBT, agi, scanfunc_ino); +} + +static int +scan_ag( + xfs_agnumber_t agno) +{ + xfs_agf_t *agf; + xfs_agi_t *agi; + + /* copy the superblock of the AG */ + push_cur(); + set_cur(&typtab[TYP_SB], XFS_AG_DADDR(mp, agno, XFS_SB_DADDR), + XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); + if (!iocur_top->data) { + print_warning("cannot read superblock for ag %u", agno); + if (stop_on_read_error) + return 0; + } else { + if (!write_buf(iocur_top)) + return 0; + } + + /* copy the AG free space btree root */ + push_cur(); + set_cur(&typtab[TYP_AGF], XFS_AG_DADDR(mp, agno, XFS_AGF_DADDR(mp)), + XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); + agf =3D iocur_top->data; + if (iocur_top->data =3D=3D NULL) { + print_warning("cannot read agf block for ag %u", agno); + if (stop_on_read_error) + return 0; + } else { + if (!write_buf(iocur_top)) + return 0; + } + + /* copy the AG inode btree root */ + push_cur(); + set_cur(&typtab[TYP_AGI], XFS_AG_DADDR(mp, agno, XFS_AGI_DADDR(mp)), + XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); + agi =3D iocur_top->data; + if (iocur_top->data =3D=3D NULL) { + print_warning("cannot read agi block for ag %u", agno); + if (stop_on_read_error) + return 0; + } else { + if (!write_buf(iocur_top)) + return 0; + } + + /* copy the AG free list header */ + push_cur(); + set_cur(&typtab[TYP_AGFL], XFS_AG_DADDR(mp, agno, XFS_AGFL_DADDR(mp)), + XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); + if (iocur_top->data =3D=3D NULL) { + print_warning("cannot read agfl block for ag %u", agno); + if (stop_on_read_error) + return 0; + } else { + if (!write_buf(iocur_top)) + return 0; + } + pop_cur(); + + /* copy AG free space btrees */ + if (agf) { + if (show_progress) + print_progress("Copying free space trees of AG %u", + agno); + if (!copy_free_bno_btree(agno, agf)) + return 0; + if (!copy_free_cnt_btree(agno, agf)) + return 0; + } + + /* copy inode btrees and the inodes and their associated metadata */ + if (agi) { + if (!copy_inodes(agno, agi)) + return 0; + } + + pop_cur(); + pop_cur(); + pop_cur(); + + return 1; +} + +static int +copy_ino( + xfs_ino_t ino, + typnm_t itype) +{ + xfs_agnumber_t agno; + xfs_agblock_t agbno; + xfs_agino_t agino; + xfs_dinode_t *dip; + xfs_dinode_core_t tdic; + int offset; + + if (ino =3D=3D 0) + return 1; + + agno =3D XFS_INO_TO_AGNO(mp, ino); + agino =3D XFS_INO_TO_AGINO(mp, ino); + agbno =3D XFS_AGINO_TO_AGBNO(mp, agino); + offset =3D XFS_AGINO_TO_OFFSET(mp, agino); + + if (agno >=3D mp->m_sb.sb_agcount || agbno >=3D mp->m_sb.sb_agblocks || + offset >=3D mp->m_sb.sb_inopblock) { + if (wflag) + print_warning("invalid %s inode number (%lld)", + typtab[itype].name, (long long)ino); + return 1; + } + + push_cur(); + set_cur(&typtab[TYP_INODE], XFS_AGB_TO_DADDR(mp, agno, agbno), + blkbb, DB_RING_IGN, NULL); + if (iocur_top->data =3D=3D NULL) { + print_warning("cannot read %s inode %lld", + typtab[itype].name, (long long)ino); + return !stop_on_read_error; + } + off_cur(offset << mp->m_sb.sb_inodelog, mp->m_sb.sb_inodesize); + + dip =3D iocur_top->data; + libxfs_xlate_dinode_core((xfs_caddr_t)&dip->di_core, &tdic, 1); + memcpy(&dip->di_core, &tdic, sizeof(xfs_dinode_core_t)); + + return process_inode_data(ino, dip, itype); +} + + +static int +copy_sb_inodes(void) +{ + if (!copy_ino(mp->m_sb.sb_rbmino, TYP_RTBITMAP)) + return 0; + + if (!copy_ino(mp->m_sb.sb_rsumino, TYP_RTSUMMARY)) + return 0; + + if (!copy_ino(mp->m_sb.sb_uquotino, TYP_DQBLK)) + return 0; + + return copy_ino(mp->m_sb.sb_gquotino, TYP_DQBLK); +} + +static int +copy_log(void) +{ + if (show_progress) + print_progress("Copying log"); + + push_cur(); + set_cur(&typtab[TYP_LOG], XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), + mp->m_sb.sb_logblocks * blkbb, DB_RING_IGN, NULL); + if (iocur_top->data =3D=3D NULL) { + print_warning("cannot read log"); + return !stop_on_read_error; + } + return write_buf(iocur_top); +} + +static int +metadump_f( + int argc, + char **argv) +{ + xfs_agnumber_t agno; + int c; + int start_iocur_sp; + + exitcode =3D 1; + show_progress =3D 0; + wflag =3D 0; + stop_on_read_error =3D 0; + + if (mp->m_sb.sb_magicnum !=3D XFS_SB_MAGIC) { + print_warning("bad superblock magic number %x, giving up", + mp->m_sb.sb_magicnum); + return 0; + } + + while ((c =3D getopt(argc, argv, "egw")) !=3D EOF) { + switch (c) { + case 'e': + stop_on_read_error =3D 1; + break; + case 'g': + show_progress =3D 1; + break; + case 'w': + wflag =3D 1; + break; + default: + print_warning("bad option for metadump command"); + return 0; + } + } + + if (optind !=3D argc - 1) { + print_warning("too few options for metadump (no filename given)"); + return 0; + } + + metablock =3D (xfs_metablock_t *)calloc(BBSIZE + 1, BBSIZE); + if (metablock =3D=3D NULL) { + print_warning("memory allocation failure"); + return 0; + } + metablock->mb_blocklog =3D BBSHIFT; + metablock->mb_magic =3D cpu_to_be32(XFS_MD_MAGIC); + + block_index =3D (__be64 *)((char *)metablock + sizeof(xfs_metablock_t)); + block_buffer =3D (char *)metablock + BBSIZE; + num_indicies =3D (BBSIZE - sizeof(xfs_metablock_t)) / sizeof(__be64); + cur_index =3D 0; + start_iocur_sp =3D iocur_sp; + + if (strcmp(argv[optind], "-") =3D=3D 0) { + if (isatty(STDOUT_FILENO)) { + print_warning("cannot write to a terminal"); + free(metablock); + return 0; + } + fd =3D STDOUT_FILENO; + } else { + fd =3D open(argv[optind], O_WRONLY | O_CREAT | O_TRUNC, 0666); + if (fd =3D=3D -1) { + print_warning("cannot create dump file"); + free(metablock); + return 0; + } + } + + exitcode =3D 0; + + for (agno =3D 0; agno < mp->m_sb.sb_agcount; agno++) { + if (!scan_ag(agno)) { + exitcode =3D 1; + break; + } + } + + /* copy realtime and quota inode contents */ + if (!exitcode) + exitcode =3D !copy_sb_inodes(); + + /* copy log if it's internal */ + if ((mp->m_sb.sb_logstart !=3D 0) && !exitcode) + exitcode =3D !copy_log(); + + /* write the remaining index */ + if (!exitcode) + exitcode =3D !write_index(); + + if (fd !=3D STDOUT_FILENO) + close(fd); + + /* cleanup iocur stack */ + while (iocur_sp > start_iocur_sp) + pop_cur(); + + free(metablock); + + if (progress_since_warning) + fputc('\n', (fd =3D=3D STDOUT_FILENO) ? stderr : stdout); + + return 0; +} + +static void +remount( + xfs_sb_t *sb) +{ + libxfs_umount(mp); + + if (!libxfs_mount(mp, sb, x.ddev, x.logdev, x.rtdev, + LIBXFS_MOUNT_ROOTINOS | LIBXFS_MOUNT_DEBUGGER)) { + if (!libxfs_mount(mp, sb, x.ddev, x.logdev, x.rtdev, + LIBXFS_MOUNT_DEBUGGER)) { + print_warning("cannot remount the filesystem"); + exit(1); + } + } + blkbb =3D 1 << mp->m_blkbb_log; +} + +static int +perform_restore(void) +{ + xfs_metablock_t tmb; + int bsize; + xfs_sb_t sb; + int bbpb; + __int64_t bbs_read; + int success; + + /* + * read in first block (superblock 0), set "inprogress" flag for it, + * read in the rest of the file, and if complete, clear SB 0's + * "inprogress flag" + */ + + if (read(fd, &tmb, sizeof(tmb)) =3D=3D -1) { + print_warning("error reading from file: %s", strerror(errno)); + return 0; + } + + if (be32_to_cpu(tmb.mb_magic) !=3D XFS_MD_MAGIC) { + print_warning("specified file is not a metadata dump"); + return 0; + } + + bsize =3D 1 << tmb.mb_blocklog; + metablock =3D (xfs_metablock_t *)calloc(bsize + 1, bsize); + if (metablock =3D=3D NULL) { + print_warning("memory allocation failure"); + return 0; + } + metablock->mb_count =3D be16_to_cpu(tmb.mb_count); + metablock->mb_blocklog =3D tmb.mb_blocklog; + + num_indicies =3D (bsize - sizeof(xfs_metablock_t)) / sizeof(__be64); + + if (metablock->mb_count =3D=3D 0 || metablock->mb_count > num_indicies) { + print_warning("bad block count: %u", metablock->mb_count); + return 0; + } + + block_index =3D (__be64 *)((char *)metablock + sizeof(xfs_metablock_t)); + block_buffer =3D (char *)metablock + bsize; + + if (read(fd, block_index, bsize - sizeof(tmb)) =3D=3D -1) { + print_warning("error reading from file: %s", strerror(errno)); + return 0; + } + + if (be64_to_cpu(block_index[0]) !=3D XFS_AG_DADDR(mp, 0, XFS_SB_DADDR)) { + print_warning("first block is not the primary superblock"); + return 0; + } + + if (read(fd, block_buffer, + metablock->mb_count << metablock->mb_blocklog) =3D=3D -1) { + print_warning("error reading from file: %s", strerror(errno)); + return 0; + } + + libxfs_xlate_sb(block_buffer, &sb, 1, XFS_SB_ALL_BITS); + + if (sb.sb_magicnum !=3D XFS_SB_MAGIC) { + print_warning("bad magic number for primary superblock"); + return 0; + } + + /* purge all cached data before writing to device */ + libxfs_bcache_purge(); + libxfs_icache_purge(); + + ((xfs_sb_t*)block_buffer)->sb_inprogress =3D 1; + cur_index =3D 1 << (sb.sb_sectlog - BBSHIFT); + + if (write_bbs(XFS_SB_DADDR, cur_index, block_buffer, NULL)) { + print_warning("error writing primary superblock: %s", + strerror(errno)); + return 0; + } + + bbpb =3D 1 << (metablock->mb_blocklog - BBSHIFT); + bbs_read =3D 0; + success =3D 0; + + + /* write the rest of the file out */ + for (;;) { + if (show_progress && (bbs_read & 2047) =3D=3D 0) + print_progress("%lld MB read", bbs_read >> 11); + + for (; cur_index < metablock->mb_count; cur_index++) { + if (write_bbs(be64_to_cpu(block_index[cur_index]), + bbpb, &block_buffer[cur_index << + metablock->mb_blocklog], + NULL)) { + print_warning("error writing block %llu: %s", + be64_to_cpu(block_index[cur_index]), + strerror(errno)); + remount(&sb); + return 0; + } + } + if (metablock->mb_count < num_indicies) { + success =3D 1; + break; + } + + if (read(fd, metablock, bsize) =3D=3D -1) { + print_warning("error reading from file: %s", + strerror(errno)); + break; + } + if (metablock->mb_count =3D=3D 0) { + success =3D 1; + break; + } + + metablock->mb_count =3D be16_to_cpu(metablock->mb_count); + + if (read(fd, block_buffer, metablock->mb_count << + metablock->mb_blocklog) =3D=3D -1) { + print_warning("error reading from file: %s", + strerror(errno)); + break; + } + + bbs_read +=3D bbpb; + + cur_index =3D 0; + if (seenint()) + break; + } + + if (progress_since_warning) + fputc('\n', (fd =3D=3D STDOUT_FILENO) ? stderr : stdout); + + if (success) { + memset(block_buffer, 0, sb.sb_sectsize); + sb.sb_inprogress =3D 0; + libxfs_xlate_sb(block_buffer, &sb, 0, XFS_SB_ALL_BITS); + if (write_bbs(XFS_SB_DADDR, 1 << (sb.sb_sectlog - BBSHIFT), + block_buffer, NULL)) { + print_warning("error writing primary superblock: %s", + strerror(errno)); + success =3D 0; + } + } + remount(&sb); + + return success; +} + +static int +metarestore_f( + int argc, + char **argv) +{ + int c; + + exitcode =3D 1; + show_progress =3D 0; + + while ((c =3D getopt(argc, argv, "g")) !=3D EOF) { + switch (c) { + case 'g': + show_progress =3D 1; + break; + default: + print_warning("bad option for metarestore " + "command"); + return 0; + } + } + + if (optind !=3D argc - 1) { + print_warning("too few options for metarestore (no filename " + "given)"); + return 0; + } + + if (strcmp(argv[optind], "-") =3D=3D 0) { + if (isatty(STDIN_FILENO)) { + print_warning("cannot read from a terminal"); + return 0; + } + fd =3D STDIN_FILENO; + } else { + fd =3D open(argv[optind], O_RDONLY, 0666); + if (fd =3D=3D -1) { + print_warning("cannot open dump file"); + return 0; + } + } + + metablock =3D NULL; + + exitcode =3D !perform_restore(); + + if (metablock !=3D NULL) + free(metablock); + + if (fd !=3D STDIN_FILENO) + close(fd); + + return 0; +} + =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xfsprogs/db/metadump.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=3D=3D=3D=3D=3D=3D=3D=3D --- a/xfsprogs/db/metadump.h 2007-02-13 17:29:33.000000000 +1100 +++ b/xfsprogs/db/metadump.h 2007-01-30 15:14:58.453299539 +1100 @@ -0,0 +1,19 @@ +/* + * 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 + */ + +extern void metadump_init(void); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xfsprogs/db/xfs_metadump.sh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- a/xfsprogs/db/xfs_metadump.sh 2007-02-13 17:29:33.000000000 +1100 +++ b/xfsprogs/db/xfs_metadump.sh 2007-02-13 16:05:27.003359183 +1100 @@ -0,0 +1,37 @@ +#!/bin/sh -f +# +# Copyright (c) 2007 Silicon Graphics, Inc. All Rights Reserved. +# + +OPTS=3D" " +DBOPTS=3D" " +USAGE=3D"Usage: xfs_metadump [-efgwV] [-l logdev] source target" + +while getopts "efgl:wV" c +do + case $c in + e) OPTS=3D$OPTS"-e ";; + g) OPTS=3D$OPTS"-g ";; + w) OPTS=3D$OPTS"-w ";; + f) DBOPTS=3D$DBOPTS" -f";; + l) DBOPTS=3D$DBOPTS" -l "$OPTARG" ";; + V) xfs_db -p xfs_metadump -V + status=3D$? + exit $status + ;; + \?) echo $USAGE 1>&2 + exit 2 + ;; + esac +done +set -- extra $@ +shift $OPTIND +case $# in + 2) xfs_db$DBOPTS -i -p xfs_metadump -c "metadump$OPTS $2" $1 + status=3D$? + ;; + *) echo $USAGE 1>&2 + exit 2 + ;; +esac +exit $status ------=_NextPart_000_008F_01C74F96.8FAF0850-- From owner-xfs@oss.sgi.com Mon Feb 12 23:41:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 12 Feb 2007 23:41:24 -0800 (PST) X-Spam-oss-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, J_CHICKENPOX_42 autolearn=no version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1D7fBm7010740 for ; Mon, 12 Feb 2007 23:41:14 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28773; Tue, 13 Feb 2007 18:41:02 +1100 Date: Tue, 13 Feb 2007 18:41:18 +1100 From: Timothy Shimmin To: Eric Sandeen , xfs@oss.sgi.com Subject: Re: [PATCH] remove unused "lsn" argument of xfs_trans_commit Message-ID: <37EB31D054F1B23EE06E3692@timothy-shimmins-power-mac-g5.local> In-Reply-To: <45C95BAF.6080005@sandeen.net> References: <45C95BAF.6080005@sandeen.net> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 10635 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 20853 Lines: 592 Sounds a good idea. I was curious why we actually have it and looked at the IRIX code. ---------------------------- revision 1.97 date: 1998/01/18 09:05:49; author: rcc; state: Exp; lines: +11 -3 added extra argument to xfs_trans_commit for IO_DSYNC speedup. pv: 555963 rv: lord@cray ---------------------------- It uses the lsn from a commit in a subsequent log force to ensure the iclog sync'ed has that transaction I assume. And I think in the linux code we get the lsn from the inode item, iip->ili_last_lsn... --Tim --On 6 February 2007 10:55:11 PM -0600 Eric Sandeen wrote: > The last argument "lsn" of xfs_trans_commit() is always called with NULL. > dmapi/xfs_dm.c | 4 ++-- > quota/xfs_dquot.c | 3 +-- > quota/xfs_qm.c | 5 ++--- > quota/xfs_qm_syscalls.c | 6 +++--- > xfs_attr.c | 12 ++++-------- > xfs_attr_leaf.c | 2 +- > xfs_bmap.c | 4 ++-- > xfs_dfrag.c | 2 +- > xfs_fsops.c | 4 ++-- > xfs_inode.c | 2 +- > xfs_iomap.c | 7 +++---- > xfs_log_recover.c | 4 ++-- > xfs_mount.c | 2 +- > xfs_qmops.c | 2 +- > xfs_rename.c | 2 +- > xfs_rtalloc.c | 6 +++--- > xfs_rw.c | 4 ++-- > xfs_trans.c | 6 ------ > xfs_trans.h | 4 +--- > xfs_utils.c | 5 ++--- > xfs_vfsops.c | 2 +- > xfs_vnodeops.c | 33 ++++++++++++++++----------------- > 22 files changed, 52 insertions(+), 69 deletions(-) > Signed-off-by: Eric Sandeen > --- > Index: linux/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- linux/fs/xfs.orig/dmapi/xfs_dm.c > +++ linux/fs/xfs/dmapi/xfs_dm.c > @@ -1168,7 +1168,7 @@ xfs_dm_f_set_eventlist( > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > VN_HOLD(vp); > - xfs_trans_commit(tp, 0, NULL); > + xfs_trans_commit(tp, 0); > return(0); > } > @@ -3021,7 +3021,7 @@ xfs_dm_set_region( > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > VN_HOLD(vp); > - xfs_trans_commit(tp, 0, NULL); > + xfs_trans_commit(tp, 0); > /* Return the proper value for *exactflagp depending upon whether or not > we "changed" the user's managed region. In other words, if the user > Index: linux/fs/xfs/quota/xfs_dquot.c > =================================================================== > --- linux/fs/xfs.orig/quota/xfs_dquot.c > +++ linux/fs/xfs/quota/xfs_dquot.c > @@ -753,8 +753,7 @@ xfs_qm_idtodq( > goto error0; > } > if (tp) { > - if ((error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, > - NULL))) > + if ((error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES))) > goto error1; > } > Index: linux/fs/xfs/quota/xfs_qm.c > =================================================================== > --- linux/fs/xfs.orig/quota/xfs_qm.c > +++ linux/fs/xfs/quota/xfs_qm.c > @@ -1453,8 +1453,7 @@ xfs_qm_qino_alloc( > XFS_SB_UNLOCK(mp, s); > xfs_mod_sb(tp, sbfields); > - if ((error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, > - NULL))) { > + if ((error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES))) { > xfs_fs_cmn_err(CE_ALERT, mp, "XFS qino_alloc failed!"); > return error; > } > @@ -2405,7 +2404,7 @@ xfs_qm_write_sb_changes( > } > xfs_mod_sb(tp, flags); > - (void) xfs_trans_commit(tp, 0, NULL); > + (void) xfs_trans_commit(tp, 0); > return 0; > } > Index: linux/fs/xfs/quota/xfs_qm_syscalls.c > =================================================================== > --- linux/fs/xfs.orig/quota/xfs_qm_syscalls.c > +++ linux/fs/xfs/quota/xfs_qm_syscalls.c > @@ -735,7 +735,7 @@ xfs_qm_scall_setqlim( > xfs_trans_log_dquot(tp, dqp); > xfs_dqtrace_entry(dqp, "Q_SETQLIM: COMMIT"); > - xfs_trans_commit(tp, 0, NULL); > + xfs_trans_commit(tp, 0); > xfs_qm_dqprint(dqp); > xfs_qm_dqrele(dqp); > mutex_unlock(&(XFS_QI_QOFFLOCK(mp))); > @@ -809,7 +809,7 @@ xfs_qm_log_quotaoff_end( > * We don't care about quotoff's performance. > */ > xfs_trans_set_sync(tp); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > return (error); > } > @@ -852,7 +852,7 @@ xfs_qm_log_quotaoff( > * We don't care about quotoff's performance. > */ > xfs_trans_set_sync(tp); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > error0: > if (error) { > Index: linux/fs/xfs/xfs_attr.c > =================================================================== > --- linux/fs/xfs.orig/xfs_attr.c > +++ linux/fs/xfs/xfs_attr.c > @@ -328,8 +328,7 @@ xfs_attr_set_int(xfs_inode_t *dp, const xfs_trans_set_sync(args.trans); > } > err2 = xfs_trans_commit(args.trans, > - XFS_TRANS_RELEASE_LOG_RES, > - NULL); > + XFS_TRANS_RELEASE_LOG_RES); > xfs_iunlock(dp, XFS_ILOCK_EXCL); > /* > @@ -397,8 +396,7 @@ xfs_attr_set_int(xfs_inode_t *dp, const * Commit the last in the sequence > of transactions. > */ > xfs_trans_log_inode(args.trans, dp, XFS_ILOG_CORE); > - error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES, > - NULL); > + error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES); > xfs_iunlock(dp, XFS_ILOCK_EXCL); > /* > @@ -544,8 +542,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, con > * Commit the last in the sequence of transactions. > */ > xfs_trans_log_inode(args.trans, dp, XFS_ILOG_CORE); > - error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES, > - NULL); > + error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES); > xfs_iunlock(dp, XFS_ILOCK_EXCL); > /* > @@ -859,8 +856,7 @@ xfs_attr_inactive(xfs_inode_t *dp) > * Commit the last in the sequence of transactions. > */ > xfs_trans_log_inode(trans, dp, XFS_ILOG_CORE); > - error = xfs_trans_commit(trans, XFS_TRANS_RELEASE_LOG_RES, > - NULL); > + error = xfs_trans_commit(trans, XFS_TRANS_RELEASE_LOG_RES); > xfs_iunlock(dp, XFS_ILOCK_EXCL); > return(error); > Index: linux/fs/xfs/xfs_attr_leaf.c > =================================================================== > --- linux/fs/xfs.orig/xfs_attr_leaf.c > +++ linux/fs/xfs/xfs_attr_leaf.c > @@ -3053,7 +3053,7 @@ xfs_attr_rolltrans(xfs_trans_t **transp, > * is in progress. The caller takes the responsibility to cancel > * the duplicate transaction that gets returned. > */ > - if ((error = xfs_trans_commit(trans, 0, NULL))) > + if ((error = xfs_trans_commit(trans, 0))) > return (error); > trans = *transp; > Index: linux/fs/xfs/xfs_bmap.c > =================================================================== > --- linux/fs/xfs.orig/xfs_bmap.c > +++ linux/fs/xfs/xfs_bmap.c > @@ -4071,7 +4071,7 @@ xfs_bmap_add_attrfork( > } > if ((error = xfs_bmap_finish(&tp, &flist, &committed))) > goto error2; > - error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); > ASSERT(ip->i_df.if_ext_max == > XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); > return error; > @@ -4227,7 +4227,7 @@ xfs_bmap_finish( > logres = ntp->t_log_res; > logcount = ntp->t_log_count; > ntp = xfs_trans_dup(*tp); > - error = xfs_trans_commit(*tp, 0, NULL); > + error = xfs_trans_commit(*tp, 0); > *tp = ntp; > *committed = 1; > /* > Index: linux/fs/xfs/xfs_dfrag.c > =================================================================== > --- linux/fs/xfs.orig/xfs_dfrag.c > +++ linux/fs/xfs/xfs_dfrag.c > @@ -382,7 +382,7 @@ xfs_swap_extents( > xfs_trans_set_sync(tp); > } > - error = xfs_trans_commit(tp, XFS_TRANS_SWAPEXT, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_SWAPEXT); > locked = 0; > error0: > Index: linux/fs/xfs/xfs_fsops.c > =================================================================== > --- linux/fs/xfs.orig/xfs_fsops.c > +++ linux/fs/xfs/xfs_fsops.c > @@ -346,7 +346,7 @@ xfs_growfs_data_private( > xfs_trans_mod_sb(tp, XFS_TRANS_SB_FDBLOCKS, nfree); > if (dpct) > xfs_trans_mod_sb(tp, XFS_TRANS_SB_IMAXPCT, dpct); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > if (error) { > return error; > } > @@ -605,7 +605,7 @@ xfs_fs_log_dummy( > xfs_trans_ihold(tp, ip); > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > xfs_trans_set_sync(tp); > - xfs_trans_commit(tp, 0, NULL); > + xfs_trans_commit(tp, 0); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > } > Index: linux/fs/xfs/xfs_inode.c > =================================================================== > --- linux/fs/xfs.orig/xfs_inode.c > +++ linux/fs/xfs/xfs_inode.c > @@ -1746,7 +1746,7 @@ xfs_itruncate_finish( > xfs_trans_log_inode(ntp, ip, XFS_ILOG_CORE); > } > ntp = xfs_trans_dup(ntp); > - (void) xfs_trans_commit(*tp, 0, NULL); > + (void) xfs_trans_commit(*tp, 0); > *tp = ntp; > error = xfs_trans_reserve(ntp, 0, XFS_ITRUNCATE_LOG_RES(mp), 0, > XFS_TRANS_PERM_LOG_RES, > Index: linux/fs/xfs/xfs_iomap.c > =================================================================== > --- linux/fs/xfs.orig/xfs_iomap.c > +++ linux/fs/xfs/xfs_iomap.c > @@ -543,7 +543,7 @@ xfs_iomap_write_direct( > error = xfs_bmap_finish(&tp, &free_list, &committed); > if (error) > goto error0; > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > if (error) > goto error_out; > @@ -840,8 +840,7 @@ xfs_iomap_write_allocate( > if (error) > goto trans_cancel; > - error = xfs_trans_commit(tp, > - XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > if (error) > goto error0; > @@ -948,7 +947,7 @@ xfs_iomap_write_unwritten( > if (error) > goto error_on_bmapi_transaction; > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > if (error) > return XFS_ERROR(error); > Index: linux/fs/xfs/xfs_log_recover.c > =================================================================== > --- linux/fs/xfs.orig/xfs_log_recover.c > +++ linux/fs/xfs/xfs_log_recover.c > @@ -3016,7 +3016,7 @@ xlog_recover_process_efi( > } > efip->efi_flags |= XFS_EFI_RECOVERED; > - xfs_trans_commit(tp, 0, NULL); > + xfs_trans_commit(tp, 0); > } > /* > @@ -3143,7 +3143,7 @@ xlog_recover_clear_agi_bucket( > xfs_trans_log_buf(tp, agibp, offset, > (offset + sizeof(xfs_agino_t) - 1)); > - (void) xfs_trans_commit(tp, 0, NULL); > + (void) xfs_trans_commit(tp, 0); > } > /* > Index: linux/fs/xfs/xfs_mount.c > =================================================================== > --- linux/fs/xfs.orig/xfs_mount.c > +++ linux/fs/xfs/xfs_mount.c > @@ -1653,7 +1653,7 @@ xfs_mount_log_sbunit( > return; > } > xfs_mod_sb(tp, fields); > - xfs_trans_commit(tp, 0, NULL); > + xfs_trans_commit(tp, 0); > } > Index: linux/fs/xfs/xfs_qmops.c > =================================================================== > --- linux/fs/xfs.orig/xfs_qmops.c > +++ linux/fs/xfs/xfs_qmops.c > @@ -78,7 +78,7 @@ xfs_mount_reset_sbqflags(xfs_mount_t *mp > return error; > } > xfs_mod_sb(tp, XFS_SB_QFLAGS); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > return error; > } > Index: linux/fs/xfs/xfs_rename.c > =================================================================== > --- linux/fs/xfs.orig/xfs_rename.c > +++ linux/fs/xfs/xfs_rename.c > @@ -584,7 +584,7 @@ xfs_rename( > * trans_commit will unlock src_ip, target_ip & decrement > * the vnode references. > */ > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > if (target_ip != NULL) { > xfs_refcache_purge_ip(target_ip); > IRELE(target_ip); > Index: linux/fs/xfs/xfs_rtalloc.c > =================================================================== > --- linux/fs/xfs.orig/xfs_rtalloc.c > +++ linux/fs/xfs/xfs_rtalloc.c > @@ -150,7 +150,7 @@ xfs_growfs_rt_alloc( > error = xfs_bmap_finish(&tp, &flist, &committed); > if (error) > goto error_exit; > - xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > /* > * Now we need to clear the allocated blocks. > * Do this one block per transaction, to keep it simple. > @@ -187,7 +187,7 @@ xfs_growfs_rt_alloc( > /* > * Commit the transaction. > */ > - xfs_trans_commit(tp, 0, NULL); > + xfs_trans_commit(tp, 0); > } > /* > * Go on to the next extent, if any. > @@ -2042,7 +2042,7 @@ xfs_growfs_rt( > /* > * Commit the transaction. > */ > - xfs_trans_commit(tp, 0, NULL); > + xfs_trans_commit(tp, 0); > } > if (error) > Index: linux/fs/xfs/xfs_rw.c > =================================================================== > --- linux/fs/xfs.orig/xfs_rw.c > +++ linux/fs/xfs/xfs_rw.c > @@ -83,7 +83,7 @@ xfs_write_clear_setuid( > } > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > xfs_trans_set_sync(tp); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > return 0; > } > @@ -164,7 +164,7 @@ xfs_write_sync_logforce( > xfs_trans_ihold(tp, ip); > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > xfs_trans_set_sync(tp); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > } > } > Index: linux/fs/xfs/xfs_trans.c > =================================================================== > --- linux/fs/xfs.orig/xfs_trans.c > +++ linux/fs/xfs/xfs_trans.c > @@ -753,7 +753,6 @@ int > _xfs_trans_commit( > xfs_trans_t *tp, > uint flags, > - xfs_lsn_t *commit_lsn_p, > int *log_flushed) > { > xfs_log_iovec_t *log_vector; > @@ -812,8 +811,6 @@ shut_us_down: > xfs_trans_free_busy(tp); > xfs_trans_free(tp); > XFS_STATS_INC(xs_trans_empty); > - if (commit_lsn_p) > - *commit_lsn_p = commit_lsn; > return (shutdown); > } > ASSERT(tp->t_ticket != NULL); > @@ -864,9 +861,6 @@ shut_us_down: > kmem_free(log_vector, nvec * sizeof(xfs_log_iovec_t)); > } > - if (commit_lsn_p) > - *commit_lsn_p = commit_lsn; > - > /* > * If we got a log write error. Unpin the logitems that we > * had pinned, clean up, free trans structure, and return error. > Index: linux/fs/xfs/xfs_trans.h > =================================================================== > --- linux/fs/xfs.orig/xfs_trans.h > +++ linux/fs/xfs/xfs_trans.h > @@ -988,10 +988,8 @@ void xfs_trans_log_efd_extent(xfs_trans > xfs_extlen_t); > int _xfs_trans_commit(xfs_trans_t *, > uint flags, > - xfs_lsn_t *, > int *); > -#define xfs_trans_commit(tp, flags, lsn) \ > - _xfs_trans_commit(tp, flags, lsn, NULL) > +#define xfs_trans_commit(tp, flags) _xfs_trans_commit(tp, flags, NULL) > void xfs_trans_cancel(xfs_trans_t *, int); > void xfs_trans_ail_init(struct xfs_mount *); > xfs_lsn_t xfs_trans_push_ail(struct xfs_mount *, xfs_lsn_t); > Index: linux/fs/xfs/xfs_utils.c > =================================================================== > --- linux/fs/xfs.orig/xfs_utils.c > +++ linux/fs/xfs/xfs_utils.c > @@ -222,7 +222,7 @@ xfs_dir_ialloc( > } > ntp = xfs_trans_dup(tp); > - code = xfs_trans_commit(tp, 0, NULL); > + code = xfs_trans_commit(tp, 0); > tp = ntp; > if (committed != NULL) { > *committed = 1; > @@ -460,8 +460,7 @@ xfs_truncate_file( > XFS_TRANS_ABORT); > } else { > xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, > - NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > } > xfs_iunlock(ip, XFS_ILOCK_EXCL | XFS_IOLOCK_EXCL); > Index: linux/fs/xfs/xfs_vfsops.c > =================================================================== > --- linux/fs/xfs.orig/xfs_vfsops.c > +++ linux/fs/xfs/xfs_vfsops.c > @@ -1539,7 +1539,7 @@ xfs_syncsub( > xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); > xfs_trans_ihold(tp, ip); > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > xfs_log_force(mp, (xfs_lsn_t)0, log_flags); > } > Index: linux/fs/xfs/xfs_vnodeops.c > =================================================================== > --- linux/fs/xfs.orig/xfs_vnodeops.c > +++ linux/fs/xfs/xfs_vnodeops.c > @@ -873,7 +873,7 @@ xfs_setattr( > if (mp->m_flags & XFS_MOUNT_WSYNC) > xfs_trans_set_sync(tp); > - code = xfs_trans_commit(tp, commit_flags, NULL); > + code = xfs_trans_commit(tp, commit_flags); > } > /* > @@ -1176,7 +1176,7 @@ xfs_fsync( > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > if (flag & FSYNC_WAIT) > xfs_trans_set_sync(tp); > - error = _xfs_trans_commit(tp, 0, NULL, &log_flushed); > + error = _xfs_trans_commit(tp, 0, &log_flushed); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > } > @@ -1291,8 +1291,7 @@ xfs_inactive_free_eofblocks( > XFS_TRANS_ABORT)); > } else { > error = xfs_trans_commit(tp, > - XFS_TRANS_RELEASE_LOG_RES, > - NULL); > + XFS_TRANS_RELEASE_LOG_RES); > } > xfs_iunlock(ip, XFS_IOLOCK_EXCL | XFS_ILOCK_EXCL); > } > @@ -1406,7 +1405,7 @@ xfs_inactive_symlink_rmt( > * we need to unlock the inode since the new transaction doesn't > * have the inode attached. > */ > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > tp = ntp; > if (error) { > ASSERT(XFS_FORCED_SHUTDOWN(mp)); > @@ -1503,7 +1502,7 @@ xfs_inactive_attrs( > tp = *tpp; > mp = ip->i_mount; > ASSERT(ip->i_d.di_forkoff != 0); > - xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > error = xfs_attr_inactive(ip); > @@ -1790,7 +1789,7 @@ xfs_inactive( > * nothing we can do except to try to keep going. > */ > (void) xfs_bmap_finish(&tp, &free_list, &committed); > - (void) xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + (void) xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > } > /* > * Release the dquots held by inode, if any. > @@ -2026,7 +2025,7 @@ xfs_create( > goto abort_rele; > } > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > if (error) { > IRELE(ip); > tp = NULL; > @@ -2511,7 +2510,7 @@ xfs_remove( > goto error_rele; > } > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > if (error) { > IRELE(ip); > goto std_return; > @@ -2719,7 +2718,7 @@ xfs_link( > goto abort_return; > } > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > if (error) > goto std_return; > @@ -2936,7 +2935,7 @@ xfs_mkdir( > goto error2; > } > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > XFS_QM_DQRELE(mp, udqp); > XFS_QM_DQRELE(mp, gdqp); > if (error) { > @@ -3190,7 +3189,7 @@ xfs_rmdir( > goto std_return; > } > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > if (error) { > IRELE(cdp); > goto std_return; > @@ -3535,7 +3534,7 @@ xfs_symlink( > if (error) { > goto error2; > } > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > XFS_QM_DQRELE(mp, udqp); > XFS_QM_DQRELE(mp, gdqp); > @@ -3790,7 +3789,7 @@ xfs_set_dmattrs ( > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > IHOLD(ip); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > return error; > } > @@ -4148,7 +4147,7 @@ retry: > goto error0; > } > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > if (error) { > break; > @@ -4455,7 +4454,7 @@ xfs_free_file_space( > goto error0; > } > - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); > + error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > } > @@ -4649,7 +4648,7 @@ xfs_change_file_space( > xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > xfs_trans_set_sync(tp); > - error = xfs_trans_commit(tp, 0, NULL); > + error = xfs_trans_commit(tp, 0); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > > From owner-xfs@oss.sgi.com Tue Feb 13 01:19:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 01:19:41 -0800 (PST) X-Spam-oss-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1D9JWm7028495 for ; Tue, 13 Feb 2007 01:19:33 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 63F931CB17 for ; Tue, 13 Feb 2007 10:50:37 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m0pG+k-tE4+j for ; Tue, 13 Feb 2007 10:50:37 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 216BE12C53 for ; Tue, 13 Feb 2007 10:50:37 +0200 (IST) From: "Leon Kolchinsky" To: Subject: mkfs and mount tips? Date: Tue, 13 Feb 2007 10:48:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdPS7OFyWmoD1iaTDqA3rphjjC5GQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070213085037.216BE12C53@mail.edu.haifa.ac.il> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l1D9JYm7028500 X-archive-position: 10636 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 1512 Lines: 64 Hello All, I have Pentium II (Deschutes) with first 10GB (/dev/hda) and second 60GB(/dev/hdc) disk. After reading gentoo xfs threads on their forum and some SGI docs and FAQs I came with this options for creating FS and mounting the disks: 1) To create XFS on hda: Code: # mkfs.xfs -l internal,size=128m -d agcount=2 /dev/hda I've also seen "–d unwritten=0" option: So my question: Is it safe to add –d unwritten=0 option to increase performance like this (or will I lose some essential functionality)?: Is this how the code should look?: # mkfs.xfs -l internal,size=128m -d agcount=2 –d unwritten=0 /dev/hda 2) To prevent data lost in case of power outage(Disabling the write back cache): Add the following to local.start: Code: # hdparm -W0 /dev/hda # hdparm -W0 /dev/hdc # blktool /dev/hda wcache off # blktool /dev/hdc wcache off Right? 3) Mount options: On gentoo xfs thread it's suggested that the mount options should be "noatime,logbufs=8" But what about "osyncisdsync" mount option. "• osyncisdsync – Writes to files opened with the O_SYNC flag set will behave as if the O_DSYNC flag had been used instead. – This can result in better performance without compromising data safety. – However timestamp updates from O_SYNC writes can be lost if the system crashes. Use osyncisosync to disable this setting." So do you think it is safe to add "osyncisdsync" mount option to fstab? I'd appreciate any comments/tips/answers. Best Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Tue Feb 13 01:36:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 01:36:21 -0800 (PST) X-Spam-oss-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1D9aCm7030406 for ; Tue, 13 Feb 2007 01:36:13 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 3F4FE19F1F for ; Tue, 13 Feb 2007 11:21:55 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gNcKQJZZ3K+a for ; Tue, 13 Feb 2007 11:21:55 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 0E805E07F for ; Tue, 13 Feb 2007 11:21:55 +0200 (IST) From: "Leon Kolchinsky" To: Subject: mkfs and mount tips? Date: Tue, 13 Feb 2007 11:19:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdPUBLoTmiVq+pxQ9+HoDJhn75fgQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070213092155.0E805E07F@mail.edu.haifa.ac.il> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l1D9aEm7030414 X-archive-position: 10637 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 1508 Lines: 63 Hello All, I have Pentium II (Deschutes) with first 10GB (/dev/hda) and second 60GB(/dev/hdc) disk. After reading gentoo xfs threads on their forum and some SGI docs and FAQs I came with this options for creating FS and mounting the disks: 1) To create XFS on hda: Code: # mkfs.xfs -l internal,size=128m -d agcount=2 /dev/hda I've also seen "–d unwritten=0" option: So my question: Is it safe to add –d unwritten=0 option to increase performance like this (or will I lose some essential functionality)?: Is this how the code should look?: # mkfs.xfs -l internal,size=128m -d agcount=2 –d unwritten=0 /dev/hda 2) To prevent data lost in case of power outage(Disabling the write back cache): Add the following to local.start: Code: # hdparm -W0 /dev/hda # hdparm -W0 /dev/hdc # blktool /dev/hda wcache off # blktool /dev/hdc wcache off Right? 3) Mount options: On gentoo xfs thread it's suggested that the mount options should be "noatime,logbufs=8" But what about "osyncisdsync" mount option. "• osyncisdsync – Writes to files opened with the O_SYNC flag set will behave as if the O_DSYNC flag had been used instead. – This can result in better performance without compromising data safety. – However timestamp updates from O_SYNC writes can be lost if the system crashes. Use osyncisosync to disable this setting." So do you think it is safe to add "osyncisdsync" mount option to fstab? I'd appreciate any comments/tips/answers. Best Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Tue Feb 13 01:55:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 01:55:26 -0800 (PST) X-Spam-oss-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_43,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r497472 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1D9tIm7032601 for ; Tue, 13 Feb 2007 01:55:19 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id 259D21A00B204; Tue, 13 Feb 2007 04:30:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 20B16A000875; Tue, 13 Feb 2007 04:30:20 -0500 (EST) Date: Tue, 13 Feb 2007 04:30:20 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Leon Kolchinsky cc: linux-xfs@oss.sgi.com Subject: Re: mkfs and mount tips? In-Reply-To: <20070213085037.216BE12C53@mail.edu.haifa.ac.il> Message-ID: References: <20070213085037.216BE12C53@mail.edu.haifa.ac.il> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 10638 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1812 Lines: 77 On Tue, 13 Feb 2007, Leon Kolchinsky wrote: > Hello All, > > I have Pentium II (Deschutes) with first 10GB (/dev/hda) and second > 60GB(/dev/hdc) disk. > After reading gentoo xfs threads on their forum and some SGI docs and FAQs I > came with this options for creating FS and mounting the disks: > > 1) To create XFS on hda: > > Code: > # mkfs.xfs -l internal,size=128m -d agcount=2 /dev/hda > > > I've also seen "?d unwritten=0" option: > > So my question: > Is it safe to add ?d unwritten=0 option to increase performance like this > (or will I lose some essential functionality)?: > > Is this how the code should look?: > # mkfs.xfs -l internal,size=128m -d agcount=2 ?d unwritten=0 /dev/hda > > > 2) To prevent data lost in case of power outage(Disabling the write back > cache): > Add the following to local.start: > > Code: > # hdparm -W0 /dev/hda > # hdparm -W0 /dev/hdc > # blktool /dev/hda wcache off > # blktool /dev/hdc wcache off > > > Right? > > 3) Mount options: > > On gentoo xfs thread it's suggested that the mount options should be > "noatime,logbufs=8" > > But what about "osyncisdsync" mount option. > > "? osyncisdsync > ? Writes to files opened with the O_SYNC flag set will behave as if the > O_DSYNC flag > had been used instead. > ? This can result in better performance without compromising data safety. > ? However timestamp updates from O_SYNC writes can be lost if the system > crashes. > Use osyncisosync to disable this setting." > > So do you think it is safe to add "osyncisdsync" mount option to fstab? > > > I'd appreciate any comments/tips/answers. > > > Best Regards, > Leon Kolchinsky > > > > > When I was trying out different optimizations (and what I currently use on a couple volumes is): logbufs=8,logbsize=262144,biosize=16,noatime,nodiratime,nobarrier Justin. From owner-xfs@oss.sgi.com Tue Feb 13 02:31:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 02:31:22 -0800 (PST) X-Spam-oss-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1DAVDm7005891 for ; Tue, 13 Feb 2007 02:31:14 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 036041C30D; Tue, 13 Feb 2007 12:35:34 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jcY5Fv5IBqwb; Tue, 13 Feb 2007 12:35:33 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id C89F519311; Tue, 13 Feb 2007 12:35:33 +0200 (IST) From: "Leon Kolchinsky" To: "'Justin Piszcz'" Cc: Subject: RE: mkfs and mount tips? Date: Tue, 13 Feb 2007 12:33:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdPVfS6uXttxwdQSi2jS7b+hmYTvQAAl51A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Message-Id: <20070213103533.C89F519311@mail.edu.haifa.ac.il> X-archive-position: 10639 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 2535 Lines: 101 > -----Original Message----- > From: Justin Piszcz [mailto:jpiszcz@lucidpixels.com] > Sent: Tuesday, February 13, 2007 11:30 AM > To: Leon Kolchinsky > Cc: linux-xfs@oss.sgi.com > Subject: Re: mkfs and mount tips? > > > > On Tue, 13 Feb 2007, Leon Kolchinsky wrote: > > > Hello All, > > > > I have Pentium II (Deschutes) with first 10GB (/dev/hda) and second > > 60GB(/dev/hdc) disk. > > After reading gentoo xfs threads on their forum and some SGI docs and > FAQs I > > came with this options for creating FS and mounting the disks: > > > > 1) To create XFS on hda: > > > > Code: > > # mkfs.xfs -l internal,size=128m -d agcount=2 /dev/hda > > > > > > I've also seen "?d unwritten=0" option: > > > > So my question: > > Is it safe to add ?d unwritten=0 option to increase performance like > this > > (or will I lose some essential functionality)?: > > > > Is this how the code should look?: > > # mkfs.xfs -l internal,size=128m -d agcount=2 ?d unwritten=0 /dev/hda > > > > > > 2) To prevent data lost in case of power outage(Disabling the write back > > cache): > > Add the following to local.start: > > > > Code: > > # hdparm -W0 /dev/hda > > # hdparm -W0 /dev/hdc > > # blktool /dev/hda wcache off > > # blktool /dev/hdc wcache off > > > > > > Right? > > > > 3) Mount options: > > > > On gentoo xfs thread it's suggested that the mount options should be > > "noatime,logbufs=8" > > > > But what about "osyncisdsync" mount option. > > > > "? osyncisdsync > > ? Writes to files opened with the O_SYNC flag set will behave as if the > > O_DSYNC flag > > had been used instead. > > ? This can result in better performance without compromising data > safety. > > ? However timestamp updates from O_SYNC writes can be lost if the system > > crashes. > > Use osyncisosync to disable this setting." > > > > So do you think it is safe to add "osyncisdsync" mount option to fstab? > > > > > > I'd appreciate any comments/tips/answers. > > > > > > Best Regards, > > Leon Kolchinsky > > > > > > > > > > > > When I was trying out different optimizations (and what I currently use on > a couple volumes is): > > logbufs=8,logbsize=262144,biosize=16,noatime,nodiratime,nobarrier > I think that "nobarrier" option is bad, cause power failure would corrupt your FS in this case. "nodiratime" is useless here, cause you're already using noatime which includes nodiratime AFAIK. What about "osyncisdsync" mount option, can someone recommend this based on its own experience? What are other optimization options during mkfs? Regards, Leon From owner-xfs@oss.sgi.com Tue Feb 13 03:08:02 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 03:08:15 -0800 (PST) X-Spam-oss-Status: No, score=-0.7 required=5.0 tests=BAYES_20 autolearn=ham version=3.2.0-pre1-r497472 Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1DB80m7010887 for ; Tue, 13 Feb 2007 03:08:02 -0800 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 E35A3124E5; Tue, 13 Feb 2007 11:57:30 +0100 (CET) To: "Leon Kolchinsky" Cc: "'Justin Piszcz'" , Subject: Re: mkfs and mount tips? References: <20070213103533.C89F519311@mail.edu.haifa.ac.il> From: Andi Kleen Date: 13 Feb 2007 12:57:36 +0100 In-Reply-To: <20070213103533.C89F519311@mail.edu.haifa.ac.il> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 10640 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs Content-Length: 543 Lines: 16 "Leon Kolchinsky" writes: > > What about "osyncisdsync" mount option, can someone recommend this based on > its own experience? Not sync metadata on O_SYNC writes. That's also dangerous -- might cause data corruption after crash. It is mostly a hack if you know your programs very well, but can't change them to use O_DSYNC when they only need that. Also his other options basically all just use more memory. If you have a P90 you're likely low on memory for modern standards and shouldn't use them. -Andi From owner-xfs@oss.sgi.com Tue Feb 13 04:36:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 04:36:28 -0800 (PST) X-Spam-oss-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_24 autolearn=no version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1DCaKm7025812 for ; Tue, 13 Feb 2007 04:36:21 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id D840E12C1A5; Tue, 13 Feb 2007 14:40:40 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AwcC3dQK0KfH; Tue, 13 Feb 2007 14:40:40 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 9987D1F909; Tue, 13 Feb 2007 14:40:40 +0200 (IST) From: "Leon Kolchinsky" To: "'Olaf Fr?czyk'" Cc: "'Justin Piszcz'" , Subject: RE: mkfs and mount tips? Date: Tue, 13 Feb 2007 14:38:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdPZYVMxDw6Ti2ORxGpez3pvDP+SwABcOAQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1171365268.20354.31.camel@venus.local.navi.pl> Message-Id: <20070213124040.9987D1F909@mail.edu.haifa.ac.il> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l1DCaLm7025818 X-archive-position: 10642 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 985 Lines: 41 > (...) > > > When I was trying out different optimizations (and what I currently > use on > > > a couple volumes is): > > > > > > logbufs=8,logbsize=262144,biosize=16,noatime,nodiratime,nobarrier > > > > > > > I think that "nobarrier" option is bad, cause power failure would > corrupt > > your FS in this case. > It depends on hardware. If you use SCSI with write cache turned off I > see no reason to loss data. You might use RAID with write cache (battery > powered) safely too. > I'm not sure but even (S)ATA with write cache disabled should be fine. > Thanks for the tips. 1) Is "–d unwritten=0" option is pretty safe? 2) What's the recommended value of "-d agcount=" for?: 10GB disk for web/mail/streaming server accordingly 50GB disk for web/mail/streaming server accordingly 300GB disk for web/mail/streaming server accordingly Or how can I calculate these recommended values? > Regards, > > Olaf > -- > Olaf Fr?czyk Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Tue Feb 13 04:49:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 04:49:30 -0800 (PST) X-Spam-oss-Status: No, score=1.4 required=5.0 tests=AWL,BAYES_50, FH_HOST_EQ_D_D_D_D,MIME_8BIT_HEADER,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r497472 Received: from zeus.office.navi.pl (ip-83-238-212-180.netia.com.pl [83.238.212.180]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1DCnLm7027729 for ; Tue, 13 Feb 2007 04:49:23 -0800 Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by zeus.office.navi.pl (8.13.1/8.13.1) with ESMTP id l1DBmPpw004182; Tue, 13 Feb 2007 12:48:25 +0100 Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.13.1/8.13.1) with ESMTP id l1DBES9M022506; Tue, 13 Feb 2007 12:16:45 +0100 Subject: RE: mkfs and mount tips? From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Leon Kolchinsky Cc: "'Justin Piszcz'" , linux-xfs@oss.sgi.com In-Reply-To: <20070213103533.C89F519311@mail.edu.haifa.ac.il> References: <20070213103533.C89F519311@mail.edu.haifa.ac.il> Content-Type: text/plain; charset=UTF-8 Date: Tue, 13 Feb 2007 12:14:28 +0100 Message-Id: <1171365268.20354.31.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 8bit X-archive-position: 10643 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: xfs Content-Length: 872 Lines: 28 On Tue, 2007-02-13 at 12:33 +0200, Leon Kolchinsky wrote: > > > -----Original Message----- > > From: Justin Piszcz [mailto:jpiszcz@lucidpixels.com] > > Sent: Tuesday, February 13, 2007 11:30 AM > > To: Leon Kolchinsky > > Cc: linux-xfs@oss.sgi.com > > Subject: Re: mkfs and mount tips? (...) > > When I was trying out different optimizations (and what I currently use on > > a couple volumes is): > > > > logbufs=8,logbsize=262144,biosize=16,noatime,nodiratime,nobarrier > > > > I think that "nobarrier" option is bad, cause power failure would corrupt > your FS in this case. It depends on hardware. If you use SCSI with write cache turned off I see no reason to loss data. You might use RAID with write cache (battery powered) safely too. I'm not sure but even (S)ATA with write cache disabled should be fine. Regards, Olaf -- Olaf FrÄ…czyk From owner-xfs@oss.sgi.com Tue Feb 13 10:05:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 10:06:00 -0800 (PST) X-Spam-oss-Status: No, score=0.0 required=5.0 tests=BAYES_50,SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1DI5qm7009228 for ; Tue, 13 Feb 2007 10:05:53 -0800 Received: from [172.16.145.22] (sjcc176x121.sjccnet.com [216.1.176.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id C109B1805FF93 for ; Tue, 13 Feb 2007 12:05:50 -0600 (CST) Message-ID: <45D1FDFC.20407@sandeen.net> Date: Tue, 13 Feb 2007 10:05:48 -0800 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: a modest proposal for 4kstacks & xfs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10645 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 981 Lines: 23 XFS continues to come up against 4k stacks, despite the best efforts of several people to slim down xfs a bit (and in fact it seems ok over simple storage these days), people are always able to stack up enough IO path to push the limits of a 4k stack. What would people think of adding a module parameter to xfs, i.e. modprobe xfs 4kstacks_may_break=1 or somesuch; and without this modprobe would fail on a 4kstacks kernel with a "helpful" message. This would at least require some positive action on the admin's part to acknowledge that there is some risk to using xfs with 4k stacks. (unfortunately something like the Fedora installer would of course have to add this by default when installing on xfs, maybe it could also warn the user of the risk...) I hate to further the meme of "xfs won't work with 4kstacks" but the truth is that there are IO path scenarios where it can lead to problems. What do folks think; useful? pointless? too heavy-handed? -Eric From owner-xfs@oss.sgi.com Tue Feb 13 10:10:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 10:10:40 -0800 (PST) X-Spam-oss-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1DIAXm7010078 for ; Tue, 13 Feb 2007 10:10:35 -0800 Received: from [172.16.145.22] (sjcc176x121.sjccnet.com [216.1.176.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 18F911805FF93; Tue, 13 Feb 2007 12:10:32 -0600 (CST) Message-ID: <45D1FF16.8080808@sandeen.net> Date: Tue, 13 Feb 2007 10:10:30 -0800 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Leon Kolchinsky CC: "'Justin Piszcz'" , linux-xfs@oss.sgi.com Subject: Re: mkfs and mount tips? References: <20070213103533.C89F519311@mail.edu.haifa.ac.il> In-Reply-To: <20070213103533.C89F519311@mail.edu.haifa.ac.il> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10646 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 374 Lines: 13 Leon Kolchinsky wrote: > What about "osyncisdsync" mount option, can someone recommend this based on > its own experience? [esandeen@neon linux-2.6.20]$ grep -r osyncisdsync fs/xfs/xfs_vfsops.c } else if (!strcmp(this_char, "osyncisdsync")) { "XFS: osyncisdsync is now the default, option is deprecated."); [esandeen@neon linux-2.6.20]$ -Eric From owner-xfs@oss.sgi.com Tue Feb 13 12:13:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Feb 2007 12:13:15 -0800 (PST) X-Spam-oss-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1DKD8m7022206 for ; Tue, 13 Feb 2007 12:13:10 -0800 Received: (qmail 71928 invoked from network); 13 Feb 2007 20:13:08 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 13 Feb 2007 20:13:07 -0000 X-YMail-OSG: 1Td0sVQVM1maQvpN.JfbHX1zuSs728vAojhV4.AvCWHW8mPyntt_1GPLwccu8JqZMwsMvpgGH3KOAnIUNC.tmXvCUI80LQ6keInY9oeMiKmAswdzLSL_6W7qUrJn8nVCsM40RS0880n68Wc- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id C3B821826121; Tue, 13 Feb 2007 12:13:06 -0800 (PST) Date: Tue, 13 Feb 2007 12:13:06 -0800 From: Chris Wedgwood To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: a modest proposal for 4kstacks & xfs Message-ID: <20070213201306.GA10237@tuatara.stupidest.org> References: <45D1FDFC.20407@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D1FDFC.20407@sandeen.net> X-archive-position: 10647 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 1458 Lines: 38 On Tue, Feb 13, 2007 at 10:05:48AM -0800, Eric Sandeen wrote: > XFS continues to come up against 4k stacks, despite the best efforts > of several people to slim down xfs a bit (and in fact it seems ok > over simple storage these days), people are always able to stack up > enough IO path to push the limits of a 4k stack. i'll argue "if XFS is enabled 4K stacks should be disabled" the only people this is really going to bother surely are people running stock RH kernels where XFS isn't supported anyhow > modprobe xfs 4kstacks_may_break=1 > > or somesuch; and without this modprobe would fail on a 4kstacks > kernel with a "helpful" message. won't people just add the param and continue anyhow w/o thinking about the issue(s)? > I hate to further the meme of "xfs won't work with 4kstacks" but the > truth is that there are IO path scenarios where it can lead to > problems. i have a setup here with ENOSPC conditions will wedge up tight wen using 4k stacks (the allocator has a path where it calls back into itself i think) > What do folks think; useful? pointless? too heavy-handed? i prefer kconfig magic to simply disallow compilation of XFS w/ 4k stacks, it's not in the past you had to try hard to break xfs in these conditions --- is it really much harder now? also, someone claimed gcc 4.1+ reused stack slots --- if that's the case it might make things a lot better than older compilers? checkstack.pl should show a difference though From owner-xfs@oss.sgi.com Wed Feb 14 12:48:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Feb 2007 12:48:25 -0800 (PST) X-Spam-oss-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1EKmFm7004255 for ; Wed, 14 Feb 2007 12:48:17 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA23720; Thu, 15 Feb 2007 07:48:08 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l1EKm57Y123713137; Thu, 15 Feb 2007 07:48:06 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l1EKm3iG123701168; Thu, 15 Feb 2007 07:48:03 +1100 (AEDT) Date: Thu, 15 Feb 2007 07:48:03 +1100 From: David Chinner To: Chris Wedgwood Cc: Eric Sandeen , xfs@oss.sgi.com Subject: Re: a modest proposal for 4kstacks & xfs Message-ID: <20070214204803.GR44411608@melbourne.sgi.com> References: <45D1FDFC.20407@sandeen.net> <20070213201306.GA10237@tuatara.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070213201306.GA10237@tuatara.stupidest.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 10650 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2480 Lines: 65 On Tue, Feb 13, 2007 at 12:13:06PM -0800, Chris Wedgwood wrote: > On Tue, Feb 13, 2007 at 10:05:48AM -0800, Eric Sandeen wrote: > > > XFS continues to come up against 4k stacks, despite the best efforts > > of several people to slim down xfs a bit (and in fact it seems ok > > over simple storage these days), people are always able to stack up > > enough IO path to push the limits of a 4k stack. > > i'll argue "if XFS is enabled 4K stacks should be disabled" Only way to be sure, IMO.... > the only people this is really going to bother surely are people > running stock RH kernels where XFS isn't supported anyhow > > > modprobe xfs 4kstacks_may_break=1 > > > > or somesuch; and without this modprobe would fail on a 4kstacks > > kernel with a "helpful" message. > > won't people just add the param and continue anyhow w/o thinking about > the issue(s)? > > > I hate to further the meme of "xfs won't work with 4kstacks" but the > > truth is that there are IO path scenarios where it can lead to > > problems. > > i have a setup here with ENOSPC conditions will wedge up tight wen > using 4k stacks (the allocator has a path where it calls back into > itself i think) Memory reclaim will call the writeback path if you are not within filesystem code when a kernel allocation fails. So if you fail a memory allocation and enter reclaim when you are already using half the stack.... > > What do folks think; useful? pointless? too heavy-handed? > > i prefer kconfig magic to simply disallow compilation of XFS w/ 4k > stacks, it's not in the past you had to try hard to break xfs in these > conditions --- is it really much harder now? > > also, someone claimed gcc 4.1+ reused stack slots --- if that's the > case it might make things a lot better than older compilers? > checkstack.pl should show a difference though gcc 4.0+ inline single use static functions by default, so it defeats the code we moved out of the bad functions to reduce the stack usage. IOWs, it undoes a lot of the previous things we've done to reduce stack usage in the critical path. That's why we had to add the "noinline" keywork to all our "STATIC" declarations.... Basically, the only real compiler thing you can do that changes stack usæge is turn on "optimise for size" which reduces stack usage by 20-25%. It is significant, but you can probably still blow a 4k stack if you add enough layers.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Feb 14 17:30:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Feb 2007 17:30:33 -0800 (PST) X-Spam-oss-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1F1UPm7004045 for ; Wed, 14 Feb 2007 17:30:27 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00844; Thu, 15 Feb 2007 12:18:53 +1100 Date: Thu, 15 Feb 2007 12:19:16 +1100 From: Timothy Shimmin To: Leon Kolchinsky , linux-xfs@oss.sgi.com Subject: Re: mkfs and mount tips? Message-ID: <5BFF2CB07B4CB49FEC7310C7@timothy-shimmins-power-mac-g5.local> In-Reply-To: <20070213085037.216BE12C53@mail.edu.haifa.ac.il> References: <20070213085037.216BE12C53@mail.edu.haifa.ac.il> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l1F1USm7004057 X-archive-position: 10651 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 961 Lines: 23 Hi Leon, --On 13 February 2007 10:48:15 AM +0200 Leon Kolchinsky wrote: > I've also seen "–d unwritten=0" option: > > So my question: > Is it safe to add –d unwritten=0 option to increase performance like this > (or will I lose some essential functionality)?: > My understanding (although I'm not familiar with that code), is that unwritten extents are used in space preallocation. So unless you reserve space for a file it will not have an effect. And if you do, then setting "unwritten=0" will speed up writes because it doesn't need to flag the unwritten extents and write out the extra transactions for this. If the unwritten extents aren't flagged as such then there can be a security issue where one can read old data (other's data) for these unwritten parts. In fact, the security issue on preallocation (1997-98 sgi-pv#705217) was what motivated the idea of flagging extents as unwritten in the first place. --Tim From owner-xfs@oss.sgi.com Wed Feb 14 23:43:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Feb 2007 23:43:12 -0800 (PST) X-Spam-oss-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1F7h5m7027218 for ; Wed, 14 Feb 2007 23:43:06 -0800 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l1F7h0fl005149 for ; Thu, 15 Feb 2007 16:43:03 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l1F7dhlk027418 for ; Thu, 15 Feb 2007 16:39:43 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l1F7dhO17226 for xfs@oss.sgi.com; Thu, 15 Feb 2007 16:39:43 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id l1F7dhg16853 for ; Thu, 15 Feb 2007 16:39:43 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20070215.163942.76502412 for ; Thu, 15 Feb 2007 16:39:42 +0900 Received: FROM tnessv1.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Thu Feb 15 16:39:42 2007 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by tnessv1.tnes.nec.co.jp (Postfix) with ESMTP id 93F82AE4B0 for ; Thu, 15 Feb 2007 16:39:38 +0900 (JST) Received: from TNESG9305.tnes.nec.co.jp (TNESG9305.bsd.tnes.nec.co.jp [10.1.104.199]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with SMTP id l1F7dg5l029192 for ; Thu, 15 Feb 2007 16:39:42 +0900 Message-Id: <200702150739.AA04964@TNESG9305.tnes.nec.co.jp> Date: Thu, 15 Feb 2007 16:39:52 +0900 To: xfs@oss.sgi.com Subject: [PATCH] fix the grace time in xfs_quota From: Utako Kusaka MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii X-archive-position: 10652 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: utako@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 1904 Lines: 53 Hi, When a quota limit is reached at a soft limit, xfs_quota(8) shows the incorrect grace time. Because, the subtraction with '__uint32_t' and 'time_t' are done in time_to_string(), and the result does not become a negative value, but a huge value. This patch fixes it. Example: xfs_quota> report User quota on /home/utako/mpnt (/dev/sda6) Blocks User ID Used Soft Hard Warn/Grace ---------- -------------------------------------------------- root 3145728 1000 2000 00 [--none--] utako 1000 1000 2000 00 [00:00:4294967286] <-- Group quota on /home/utako/mpnt (/dev/sda6) Blocks Group ID Used Soft Hard Warn/Grace ---------- -------------------------------------------------- root 3145728 0 0 00 [--------] users 1000 0 0 00 [--------] Signed-off-by: Utako Kusaka --- --- xfsprogs-2.8.18-orgn/quota/quota.h 2006-12-13 13:57:23.000000000 +0900 +++ xfsprogs-2.8.18/quota/quota.h 2007-02-15 11:51:20.000000000 +0900 @@ -49,7 +49,7 @@ enum { */ extern char *type_to_string(uint __type); extern char *form_to_string(uint __form); -extern char *time_to_string(__uint32_t __time, uint __flags); +extern char *time_to_string(time_t __time, uint __flags); extern char *bbs_to_string(__uint64_t __v, char *__c, uint __size); extern char *num_to_string(__uint64_t __v, char *__c, uint __size); extern char *pct_to_string(__uint64_t __v, __uint64_t __t, char *__c, uint __s); --- xfsprogs-2.8.18-orgn/quota/util.c 2006-12-13 13:57:23.000000000 +0900 +++ xfsprogs-2.8.18/quota/util.c 2007-02-15 11:51:51.000000000 +0900 @@ -29,7 +29,7 @@ char * time_to_string( - __uint32_t origin, + time_t origin, uint flags) { static char timestamp[32]; From owner-xfs@oss.sgi.com Thu Feb 15 01:16:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 15 Feb 2007 01:16:30 -0800 (PST) X-Spam-oss-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1F9GMm7014276 for ; Thu, 15 Feb 2007 01:16:25 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA11843; Thu, 15 Feb 2007 20:16:17 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l1F9GEAf011535; Thu, 15 Feb 2007 20:16:14 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l1F9GAs9011531; Thu, 15 Feb 2007 20:16:10 +1100 (AEDT) Date: Thu, 15 Feb 2007 20:16:10 +1100 From: David Chinner To: "Ramy M. Hassan " Cc: linux-kernel@vger.kernel.org, Ahmed El Zein , xfs@oss.sgi.com Subject: Re: xfs internal error on a new filesystem Message-ID: <20070215091610.GB5743@melbourne.sgi.com> References: <20070214102432.6346.qmail@info6.gawab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070214102432.6346.qmail@info6.gawab.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 10653 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2298 Lines: 76 On Wed, Feb 14, 2007 at 10:24:27AM +0000, Ramy M. Hassan wrote: > Hello, > We got the following xfs internal error on one of our production servers: > > Feb 14 08:28:52 info6 kernel: [238186.676483] Filesystem "sdd8": XFS > internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. > Caller 0xf8b906e7 Real stack looks to be: xfs_trans_cancel xfs_mkdir xfs_vn_mknod xfs_vn_mkdir vfs_mkdir sys_mkdirat sys_mkdir We aborted a transaction for some reason. We got an error somewhere in a mkdir while we had a dirty transaction. Unfortunately, this tells us very little about the error that actually caused the shutdown. What is your filessytem layout? (xfs_info ) How much memory do you have and were you near enomem conditions? > We were able to unmount/remount the volume (didn't do xfs_repair because we > thought it might take long time, and the server was already in production > at the moement) Risky to run a production system on a filesystem that might be corrupted. You risk further problems if you don't run repair.... > The file system was created less than 48hours ago, and 370G of sensitve > production data was moved to the server before it xfs crash. So that's not a "new" filesystem at all... FWIW, did you do any offline testing before you put it into production? > System details : > Kernel: 2.6.18 > Controller: 3ware 9550SX-8LP (RAID 10) Can you describe your dm/md volume layout? > We are wondering here if this problem is an indicator to data corruption on > disk ? It might be. You didn't run xfs_check or xfs_repair, so we don't know if there is any on disk corruption here. > is it really necessary to run xfs_repair ? If you want to know if you haven't left any landmines around for the filesystem to trip over again. i.e. You should run repair after any sort of XFS shutdown to make sure nothing is corrupted on disk. If nothing is corrupted on disk, then we are looking at an in-memory problem.... > Do u recommend that we switch back to reiserfs ? Not yet. > Could it be a hardware related problems ? Yes. Do you have ECC memory on your server? Have you run memtest86? Were there any I/O errors in the log prior to the shutdown message? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Feb 15 06:08:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 15 Feb 2007 06:08:53 -0800 (PST) X-Spam-oss-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1FE8jm7028055 for ; Thu, 15 Feb 2007 06:08:47 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 6DAF612C49B; Thu, 15 Feb 2007 16:13:09 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uJ5cAVJ8lnZt; Thu, 15 Feb 2007 16:13:09 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 383D619323; Thu, 15 Feb 2007 16:13:09 +0200 (IST) From: "Leon Kolchinsky" To: "'Timothy Shimmin'" , Subject: RE: mkfs and mount tips? Date: Thu, 15 Feb 2007 16:10:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdQn/HL2OHHTk4fSee/t9PiD0uWNgAaxMZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <5BFF2CB07B4CB49FEC7310C7@timothy-shimmins-power-mac-g5.local> Message-Id: <20070215141309.383D619323@mail.edu.haifa.ac.il> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id l1FE8lm7028061 X-archive-position: 10656 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 1252 Lines: 41 > -----Original Message----- > From: Timothy Shimmin [mailto:tes@sgi.com] > Sent: Thursday, February 15, 2007 3:19 AM > To: Leon Kolchinsky; linux-xfs@oss.sgi.com > Subject: Re: mkfs and mount tips? > > Hi Leon, > > --On 13 February 2007 10:48:15 AM +0200 Leon Kolchinsky > wrote: > > > I've also seen "–d unwritten=0" option: > > > > So my question: > > Is it safe to add –d unwritten=0 option to increase performance like > this > > (or will I lose some essential functionality)?: > > > > My understanding (although I'm not familiar with that code), > is that unwritten extents are used in space preallocation. > So unless you reserve space for a file it will not have an effect. > And if you do, then setting "unwritten=0" will speed up writes because it > doesn't > need to flag the unwritten extents and write out the extra transactions > for this. > If the unwritten extents aren't flagged as such then there can be a > security issue > where one can read old data (other's data) for these unwritten parts. > In fact, the security issue on preallocation (1997-98 sgi-pv#705217) was > what motivated > the idea of flagging extents as unwritten in the first place. > Thanks for clearing that out :) > --Tim From owner-xfs@oss.sgi.com Thu Feb 15 08:50:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 15 Feb 2007 08:50:13 -0800 (PST) X-Spam-oss-Status: No, score=-0.6 required=5.0 tests=BAYES_20,J_CHICKENPOX_31, MSGID_FROM_MTA_HEADER autolearn=no version=3.2.0-pre1-r497472 Received: from info11.gawab.com (info11.gawab.com [204.97.230.49]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1FGo5m7022369 for ; Thu, 15 Feb 2007 08:50:07 -0800 Received: (qmail 3231 invoked by uid 1004); 15 Feb 2007 16:19:32 -0000 Message-ID: <20070215161932.3230.qmail@info11.gawab.com> Received: from 62.135.122.243 by 11.webmail.gawab.com with HTTP; Thu, 15 Feb 2007 16:19:32 GMT From: "Ahmed El Zein" To: David Chinner Cc: "Ramy M. Hassan " , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: xfs internal error on a new filesystem Date: Thu, 15 Feb 2007 16:19:32 GMT Content-Type: text/plain ; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [62.135.122.243] X-archive-position: 10657 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: a.elzein@gawab.net Precedence: bulk X-list: xfs Content-Length: 3744 Lines: 118 David Chinner wrote on 15 Feb 2007, 11:16 AM: Subject: Re: xfs internal error on a new filesystem >On Wed, Feb 14, 2007 at 10:24:27AM +0000, Ramy M. Hassan wrote: >> Hello, >> We got the following xfs internal error on one of our production servers: >> >> Feb 14 08:28:52 info6 kernel: [238186.676483] Filesystem "sdd8": XFS >> internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. >> Caller 0xf8b906e7 > >Real stack looks to be: > > xfs_trans_cancel > xfs_mkdir > xfs_vn_mknod > xfs_vn_mkdir > vfs_mkdir > sys_mkdirat > sys_mkdir > >We aborted a transaction for some reason. We got an error somewhere in >a mkdir while we had a dirty transaction. Unfortunately, this tells us >very >little about the error that actually caused the shutdown. > >What is your filessytem layout? (xfs_info ) How much memory >do you have and were you near enomem conditions? We have 1536 MB of ram. It is possible that at the time of the crash we were near enomem conditions, I don;t know for sure but we have seen such spikes on our servers. root@info6:~# xfs_info /vol/6/ meta-data=/dev/sdd8 isize=256 agcount=16, agsize=7001584 blks = sectsz=512 attr=0 data = bsize=4096 blocks=112025248, imaxpct=25 = sunit=16 swidth=64 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 > >> We were able to unmount/remount the volume (didn't do xfs_repair because >we >> thought it might take long time, and the server was already in production >> at the moement) > >Risky to run a production system on a filesystem that might be corrupted. >You risk further problems if you don't run repair.... > >> The file system was created less than 48hours ago, and 370G of sensitve >> production data was moved to the server before it xfs crash. > >So that's not a "new" filesystem at all... By new we meant 48 hours old. > >FWIW, did you do any offline testing before you put it into production? We did some basic testing. But as a filesystem developer, how would you test a filesystem so that you would be comfortable with the stability of the filesystem and be worry free in terms of faulty hardware? > >> System details : >> Kernel: 2.6.18 >> Controller: 3ware 9550SX-8LP (RAID 10) > >Can you describe your dm/md volume layout? one unit, 8HDDs, a stripe of 4 mirrors. > >> We are wondering here if this problem is an indicator to data corruption >on >> disk ? > >It might be. You didn't run xfs_check or xfs_repair, so we don't know if >there is any on disk corruption here. > >> is it really necessary to run xfs_repair ? > >If you want to know if you haven't left any landmines around for the >filesystem to trip over again. i.e. You should run repair after any >sort of XFS shutdown to make sure nothing is corrupted on disk. >If nothing is corrupted on disk, then we are looking at an in-memory >problem.... we will run repair tonight. > >> Do u recommend that we switch back to reiserfs ? > >Not yet. > >> Could it be a hardware related problems ? > >Yes. Do you have ECC memory on your server? Have you run memtest86? >Were there any I/O errors in the log prior to the shutdown message? Yes, we have ECC memory. We will try to run memtest86 as soon as possible. There were no I/O errors in the log prior to the shutdown message. Btw, this is a vmware image. /vol/6 is an exported physical partition. >Cheers, > >Dave. >-- >Dave Chinner >Principal Engineer >SGI Australian Software Group > From owner-xfs@oss.sgi.com Thu Feb 15 21:32:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 15 Feb 2007 21:32:32 -0800 (PST) X-Spam-oss-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1G5WNm7019083 for ; Thu, 15 Feb 2007 21:32:25 -0800 Received: from [134.14.55.84] (shark.melbourne.sgi.com [134.14.55.84]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14859; Fri, 16 Feb 2007 16:32:14 +1100 Message-ID: <45D541CF.2070106@sgi.com> Date: Fri, 16 Feb 2007 16:31:59 +1100 From: Donald Douwsma User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Utako Kusaka CC: xfs@oss.sgi.com Subject: Re: [PATCH] fix the grace time in xfs_quota References: <200702150739.AA04964@TNESG9305.tnes.nec.co.jp> In-Reply-To: <200702150739.AA04964@TNESG9305.tnes.nec.co.jp> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10661 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Content-Length: 2921 Lines: 76 Hi Utako, I was unable to reproduce these results internally (sgi-xfsprogs-2.8.16-1sgi100b2chatz). But I think your patch looks good, these really should be time_t's. $ sudo /usr/sbin/xfs_quota -xc report /mnt/test User quota on /mnt/test (/dev/sdb5) Blocks User ID Used Soft Hard Warn/Grace ---------- -------------------------------------------------- bin 168 0 0 00 [--------] games 608 0 0 00 [--------] root 125948 0 0 00 [0 days] donaldd 15000 10240 20480 00 [00:00:11] $ sudo /usr/sbin/xfs_quota -xc report /mnt/test User quota on /mnt/test (/dev/sdb5) Blocks User ID Used Soft Hard Warn/Grace ---------- -------------------------------------------------- bin 168 0 0 00 [--------] games 608 0 0 00 [--------] root 125948 0 0 00 [0 days] donaldd 15000 10240 20480 00 [0 days] Thanks for the patch, Donald Utako Kusaka wrote: ... > Example: > xfs_quota> report > User quota on /home/utako/mpnt (/dev/sda6) > Blocks > User ID Used Soft Hard Warn/Grace > ---------- -------------------------------------------------- > root 3145728 1000 2000 00 [--none--] > utako 1000 1000 2000 00 [00:00:4294967286] <-- > > Group quota on /home/utako/mpnt (/dev/sda6) > Blocks > Group ID Used Soft Hard Warn/Grace > ---------- -------------------------------------------------- > root 3145728 0 0 00 [--------] > users 1000 0 0 00 [--------] > Signed-off-by: Utako Kusaka > --- > > --- xfsprogs-2.8.18-orgn/quota/quota.h 2006-12-13 13:57:23.000000000 +0900 > +++ xfsprogs-2.8.18/quota/quota.h 2007-02-15 11:51:20.000000000 +0900 > @@ -49,7 +49,7 @@ enum { > */ > extern char *type_to_string(uint __type); > extern char *form_to_string(uint __form); > -extern char *time_to_string(__uint32_t __time, uint __flags); > +extern char *time_to_string(time_t __time, uint __flags); > extern char *bbs_to_string(__uint64_t __v, char *__c, uint __size); > extern char *num_to_string(__uint64_t __v, char *__c, uint __size); > extern char *pct_to_string(__uint64_t __v, __uint64_t __t, char *__c, uint __s); > > > --- xfsprogs-2.8.18-orgn/quota/util.c 2006-12-13 13:57:23.000000000 +0900 > +++ xfsprogs-2.8.18/quota/util.c 2007-02-15 11:51:51.000000000 +0900 > @@ -29,7 +29,7 @@ > > char * > time_to_string( > - __uint32_t origin, > + time_t origin, > uint flags) > { > static char timestamp[32]; > > From owner-xfs@oss.sgi.com Thu Feb 15 23:34:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 15 Feb 2007 23:34:20 -0800 (PST) X-Spam-oss-Status: No, score=0.1 required=5.0 tests=BAYES_50,J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r497472 Received: from pd2mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1G7YEm7031835 for ; Thu, 15 Feb 2007 23:34:15 -0800 Received: from pd5mr5so.prod.shaw.ca (pd5mr5so-qfe3.prod.shaw.ca [10.0.141.181]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JDJ0017XM7NH830@l-daemon> for xfs@oss.sgi.com; Thu, 15 Feb 2007 23:33:23 -0700 (MST) Received: from pn2ml8so.prod.shaw.ca ([10.0.121.152]) by pd5mr5so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0JDJ00M2MM7NWQE0@pd5mr5so.prod.shaw.ca> for xfs@oss.sgi.com; Thu, 15 Feb 2007 23:33:23 -0700 (MST) Received: from mail.kevinjamieson.com ([24.87.84.75]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JDJ0038CM7N5OG0@l-daemon> for xfs@oss.sgi.com; Thu, 15 Feb 2007 23:33:23 -0700 (MST) Received: by mail.kevinjamieson.com (Postfix, from userid 1004) id B8E70E639C; Thu, 15 Feb 2007 22:35:28 -0800 (PST) Received: from [192.168.1.110] (bender.lan.kevinjamieson.com [192.168.1.110]) by mail.kevinjamieson.com (Postfix) with ESMTP id 9F77DE637B; Thu, 15 Feb 2007 22:35:28 -0800 (PST) Date: Thu, 15 Feb 2007 22:33:21 -0800 From: Kevin Jamieson Subject: [PATCH] dm_create_session() calls create_proc_entry() with spinlock held To: xfs@oss.sgi.com Reply-to: kjamieson@bycast.com Message-id: <45D55031.1030507@kevinjamieson.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) X-archive-position: 10662 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kevin@kevinjamieson.com Precedence: bulk X-list: xfs Content-Length: 5406 Lines: 156 dm_create_session() calls create_proc_read_entry() with the dm_session_lock spinlock held. But create_proc_entry() calls kmalloc(GFP_KERNEL), which can sleep, so this isn't safe. We have observed this to cause deadlocks with multiple processes creating/using DMAPI sessions concurrently (this was with SLES10's 2.6.16.21-0.8 kernel, but the DMAPI code in question is the same in CVS HEAD): BUG: spinlock cpu recursion on CPU#1, a1/3235 lock: f930c49c, .magic: dead4ead, .owner: a2/22546, .owner_cpu: 1 Stack traceback for pid 6144 0xdfc98270 6144 2748 1 0 R 0xdfc98450 a1 EBP EIP Function (args) 0xf0f5be24 0xc010d89f delay_tsc+0xc (0xf0f5be44) 0xf0f5be2c 0xc01cd928 __delay+0xc (0x1, 0x18, 0xf0f5be90, 0xf0f5be8c) 0xc01ceb85 _raw_spin_lock+0x79 0xf0f5be4c 0xc02afd93 _spin_lock+0x8 (0x1, 0x18, 0xf0f5be8c, 0x1) 0xf0f5be64 0xf9307302 [dmapi]dm_find_session_and_lock+0x1a (0x2220a, 0x1, 0x8fb5b198, 0x6f6b8864, 0xe) 0xf0f5bea0 0xf93062eb [dmapi]dm_app_get_tdp+0x87 (0xffffffff, 0x2, 0x1, 0xf0f5beb8, 0x3000) 0xf0f5bec0 0xf9302cf6 [dmapi]dm_read_invis_rvp+0x17 (0xffffffff, 0x27c4000, 0x0, 0x4000, 0x0) 0xf0f5bf48 0xf93014b9 [dmapi]dmapi_ioctl+0x4ab (0xab0be160, 0x28, 0xfffffff7, 0xf787f9c0, 0xab0be160) 0xf0f5bf64 0xc01700d3 do_ioctl+0x4f (0xaf345000, 0xf6f58240, 0x1b, 0x2, 0xaf3459ac) 0xf0f5bf98 0xc0170346 vfs_ioctl+0x25a (0xab0be160, 0x1, 0x1b, 0x0, 0xb7825bf0) 0xf0f5bfb4 0xc01703a9 sys_ioctl+0x50 0xc0103d1b sysenter_past_esp+0x54 Stack traceback for pid 3254 0xdfec0720 3254 2748 1 1 R 0xdfec0900 *a1 EBP EIP Function (args) 0xf6f71e40 0xc01ce862 spin_bug (0xf66cbf20, 0xffffffda, 0xf6f71ec0, 0xf6f71ebc) 0xc01ceb58 _raw_spin_lock+0x4c 0xf6f71e48 0xc02afd93 _spin_lock+0x8 (0x1, 0xffffffda, 0x0, 0xb32f01d0) 0xf6f71e60 0xf9307302 [dmapi]dm_find_session_and_lock+0x1a (0x0, 0x1, 0x0, 0x0, 0x3) 0xf6f71ed0 0xf9307538 [dmapi]dm_get_events+0x24 (0xfff, 0xad2e2ae8, 0xb32f02c8, 0x1, 0x0) 0xf6f71f48 0xf9301274 [dmapi]dmapi_ioctl+0x266 (0xb32f01d0, 0x12, 0xfffffff7, 0xf787f9c0, 0xb32f01d0) 0xf6f71f64 0xc01700d3 do_ioctl+0x4f (0x0, 0x0, 0x1b, 0xf66d31cc, 0x8517980) 0xf6f71f98 0xc0170346 vfs_ioctl+0x25a (0xb32f01d0, 0x1, 0x1b, 0xad2f7400, 0xb32f02c4) 0xf6f71fb4 0xc01703a9 sys_ioctl+0x50 0xc0103d1b sysenter_past_esp+0x54 Stack traceback for pid 12452 0xdfb047e0 12452 12451 0 1 R 0xdfb049c0 a2 EBP EIP Function (args) 0xf14cbcbc 0xc02ae254 schedule+0xb84 (0xdffff180) 0xf14cbcc8 0xc02ae33b cond_resched+0x36 (0x0, 0x1, 0xf14cbe53) 0xf14cbcdc 0xc015d07a __kmalloc+0x4a (0x1, 0x8124, 0xa, 0x8, 0xf14cbe48) 0xf14cbd04 0xc018ef93 proc_create+0x8c (0x1, 0xf784d440, 0xf14cbe34, 0xd53b5de8) 0xf14cbd1c 0xc018f045 create_proc_entry+0x5f (0xf14cbe34, 0xf9309030, 0xd53b5de8, 0x7, 0x61637942) 0xf14cbedc 0xf9307c14 [dmapi]dm_create_session+0x234 (0x0, 0x0, 0x80db388, 0xb7fccff4, 0x82fa604) 0xf14cbf48 0xf93010b0 [dmapi]dmapi_ioctl+0xa2 (0xbfd1fb00, 0x3, 0xfffffff7, 0xf1399540, 0xbfd1fb00) 0xf14cbf64 0xc01700d3 do_ioctl+0x4f (0xf54cf080, 0xf782cee4, 0x3, 0xc02b0c16, 0x0) 0xf14cbf98 0xc0170346 vfs_ioctl+0x25a (0xbfd1fb00, 0x0, 0x3, 0x82fa600, 0x2) 0xf14cbfb4 0xc01703a9 sys_ioctl+0x50 0xc0103d1b sysenter_past_esp+0x54 It doesn't appear necessary for create/remove_proc_entry() to be called with the dm_session_lock spinlock held. The following patch moves these calls outside of the spinlock. Signed-off-by: Kevin Jamieson Index: fs/dmapi/dmapi_session.c =================================================================== RCS file: /cvs/linux-2.6-xfs/fs/dmapi/dmapi_session.c,v retrieving revision 1.31 diff -u -r1.31 dmapi_session.c --- fs/dmapi/dmapi_session.c 12 Jan 2007 15:07:58 -0000 1.31 +++ fs/dmapi/dmapi_session.c 16 Feb 2007 06:14:08 -0000 @@ -519,13 +519,14 @@ sv_init(&s->sn_readerq, SV_DEFAULT, "dmreadq"); sv_init(&s->sn_writerq, SV_DEFAULT, "dmwritq"); spinlock_init(&s->sn_qlock, "sn_qlock"); - lc = mutex_spinlock(&dm_session_lock); } else { lc = mutex_spinlock(&dm_session_lock); if ((error = dm_find_session(old, &s)) != 0) { mutex_spinunlock(&dm_session_lock, lc); return(error); } + unlink_session(s); + mutex_spinunlock(&dm_session_lock, lc); #ifdef CONFIG_PROC_FS { char buf[100]; @@ -533,12 +534,13 @@ remove_proc_entry(buf, NULL); } #endif - unlink_session(s); } memcpy(s->sn_info, sessinfo, len); s->sn_info[len-1] = 0; /* if not NULL, then now 'tis */ s->sn_sessid = sid; + lc = mutex_spinlock(&dm_session_lock); link_session(s); + mutex_spinunlock(&dm_session_lock, lc); #ifdef CONFIG_PROC_FS { char buf[100]; @@ -549,7 +551,6 @@ entry->owner = THIS_MODULE; } #endif - mutex_spinunlock(&dm_session_lock, lc); return(0); } @@ -583,6 +584,12 @@ mutex_spinunlock(&dm_session_lock, lc); return(-EBUSY); } + + /* The session is not in use. Dequeue it from the session chain. */ + + unlink_session(s); + nested_spinunlock(&s->sn_qlock); + mutex_spinunlock(&dm_session_lock, lc); #ifdef CONFIG_PROC_FS { @@ -592,12 +599,6 @@ } #endif - /* The session is not in use. Dequeue it from the session chain. */ - - unlink_session(s); - nested_spinunlock(&s->sn_qlock); - mutex_spinunlock(&dm_session_lock, lc); - /* Now clear the sessions's disposition registration, and then destroy the session structure. */ From owner-xfs@oss.sgi.com Fri Feb 16 09:59:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 16 Feb 2007 09:59:14 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, J_CHICKENPOX_31 autolearn=no version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1GHx5m7017169 for ; Fri, 16 Feb 2007 09:59:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA03115; Sat, 17 Feb 2007 04:59:00 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id l1GHwtAf1866715; Sat, 17 Feb 2007 04:58:58 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l1GHwp7W1866895; Sat, 17 Feb 2007 04:58:51 +1100 (AEDT) Date: Sat, 17 Feb 2007 04:58:51 +1100 From: David Chinner To: Ahmed El Zein Cc: David Chinner , "Ramy M. Hassan " , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: xfs internal error on a new filesystem Message-ID: <20070216175851.GI5724@melbourne.sgi.com> References: <20070215161932.3230.qmail@info11.gawab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070215161932.3230.qmail@info11.gawab.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 10663 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1684 Lines: 45 On Thu, Feb 15, 2007 at 04:19:32PM +0000, Ahmed El Zein wrote: > David Chinner wrote on 15 Feb 2007, 11:16 AM: > >What is your filessytem layout? (xfs_info ) How much memory > >do you have and were you near enomem conditions? > > We have 1536 MB of ram. It is possible that at the time of the crash we > were near enomem conditions, I don;t know for sure but we have seen such > spikes on our servers. Ok, so that's a possibility. > root@info6:~# xfs_info /vol/6/ > meta-data=/dev/sdd8 isize=256 agcount=16, agsize=7001584 > blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=112025248, imaxpct=25 > = sunit=16 swidth=64 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 Nothing unusual here... > >Yes. Do you have ECC memory on your server? Have you run memtest86? > >Were there any I/O errors in the log prior to the shutdown message? > Yes, we have ECC memory. > We will try to run memtest86 as soon as possible. > There were no I/O errors in the log prior to the shutdown message. > > Btw, this is a vmware image. /vol/6 is an exported physical partition. I'd suggest trying to reproduce this problem without vmware in the picture - you need to rule out a vmware based problem first before we can really make any progress on this.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Feb 18 05:54:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Feb 2007 05:54:21 -0800 (PST) X-Spam-oss-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1IDsDm7020154 for ; Sun, 18 Feb 2007 05:54:15 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id CAA1114B25F; Sun, 18 Feb 2007 15:58:44 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EhVF57YwgUGY; Sun, 18 Feb 2007 15:58:44 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 9300C14A856; Sun, 18 Feb 2007 15:58:44 +0200 (IST) From: "Leon Kolchinsky" To: "'Ahmed El Zein'" , "'David Chinner'" Cc: "'Ramy M. Hassan '" , , Subject: RE: xfs internal error on a new filesystem Date: Sun, 18 Feb 2007 15:56:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdRIiG7SPwLE0pnQZSaMKvb/cKlogCQgjpw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070215161932.3230.qmail@info11.gawab.com> Message-Id: <20070218135844.9300C14A856@mail.edu.haifa.ac.il> X-archive-position: 10666 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 802 Lines: 37 > > > >> Do u recommend that we switch back to reiserfs ? > > > >Not yet. > > > >> Could it be a hardware related problems ? > > > >Yes. Do you have ECC memory on your server? Have you run memtest86? > >Were there any I/O errors in the log prior to the shutdown message? > Yes, we have ECC memory. > We will try to run memtest86 as soon as possible. > There were no I/O errors in the log prior to the shutdown message. > > Btw, this is a vmware image. /vol/6 is an exported physical partition. > I've read that vmware do disk caching by default and we know xfs has problem with when disaster strikes. You definitely should disable disk caching on you side. > >Cheers, > > > >Dave. > >-- > >Dave Chinner > >Principal Engineer > >SGI Australian Software Group > > > Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Sun Feb 18 14:05:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Feb 2007 14:05:57 -0800 (PST) X-Spam-oss-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1IM5qm7020192 for ; Sun, 18 Feb 2007 14:05:52 -0800 Received: from [192.168.3.11] (Athena [192.168.3.11]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l1ILcjnx003027; Sun, 18 Feb 2007 13:38:45 -0800 Message-ID: <45D8C765.7080306@tlinx.org> Date: Sun, 18 Feb 2007 13:38:45 -0800 From: Linda Walsh User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10667 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: xfs Content-Length: 2751 Lines: 76 Turned on lock testing/proving/deadlock detection. Not chasing any particular problem, but looking for things "oddities". Turned on options (under kernel hacking): Locking API boot-time self-tests RT Mutex debugging, deadlock detection Lock debugging: prove locking correctness Multiple reboots show it to be a constant. I had tried the new "Asynchronous SCSI scanning" -- thought that might have been related, but turning it off makes no difference. I'm guessing this "error" has been present before this, but the lock proving algorithms are bringing it to light? So I don't know how serious this is (if it is anything), but at the least, it doesn't look too clean... Maybe that .... SCSI device sda: write cache: enabled, read cache: enabled, supports DPO and FUA sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 > sd 0:0:0:0: Attached scsi disk sda UDF-fs: No VRS found XFS mounting filesystem sda3 Ending clean XFS mount for filesystem: sda3 VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 316k freed ============================================= [ INFO: possible recursive locking detected ] 2.6.20 #3 --------------------------------------------- rm/682 is trying to acquire lock: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x7d/0xb0 but task is already holding lock: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x7d/0xb0 other info that might help us debug this: 3 locks held by rm/682: #0: (&inode->i_mutex/1){--..}, at: [] do_unlinkat+0x96/0x170 #1: (&inode->i_mutex){--..}, at: [] vfs_unlink+0x5a/0xd0 #2: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x7d/0xb0 stack backtrace: [] __lock_acquire+0xaf1/0xdf0 [] lock_acquire+0x57/0x70 [] xfs_ilock+0x7d/0xb0 [] down_write+0x2f/0x50 [] xfs_ilock+0x7d/0xb0 [] xfs_ilock+0x7d/0xb0 [] xfs_lock_dir_and_entry+0xfd/0x100 [] xfs_remove+0x198/0x4e0 [] xfs_access+0x26/0x50 [] xfs_access+0x26/0x50 [] vfs_unlink+0x5a/0xd0 [] xfs_vn_unlink+0x23/0x60 [] __mutex_lock_slowpath+0x152/0x2a0 [] mark_held_locks+0x6b/0x90 [] __mutex_lock_slowpath+0x152/0x2a0 [] __mutex_lock_slowpath+0x152/0x2a0 [] trace_hardirqs_on+0xc7/0x170 [] __mutex_lock_slowpath+0x145/0x2a0 [] vfs_unlink+0x5a/0xd0 [] permission+0x137/0x140 [] vfs_unlink+0x90/0xd0 [] do_unlinkat+0xd3/0x170 [] do_page_fault+0x327/0x630 [] sysenter_past_esp+0x5f/0x99 ======================= XFS mounting filesystem sda1 Ending clean XFS mount for filesystem: sda1 From owner-xfs@oss.sgi.com Sun Feb 18 16:27:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Feb 2007 16:27:36 -0800 (PST) X-Spam-oss-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1J0RTm7009975 for ; Sun, 18 Feb 2007 16:27:32 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04263; Mon, 19 Feb 2007 11:27:23 +1100 Message-ID: <45D8EFA5.1060602@sgi.com> Date: Mon, 19 Feb 2007 11:30:29 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: kjamieson@bycast.com CC: xfs@oss.sgi.com Subject: Re: [PATCH] dm_create_session() calls create_proc_entry() with spinlock held References: <45D55031.1030507@kevinjamieson.com> In-Reply-To: <45D55031.1030507@kevinjamieson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10668 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 6383 Lines: 181 Hi Kevin, The patch looks good to me and I will merge it the dmapi tree. One think that should be kept in mind is that there was a race problem in remove_proc_entry() fixed in kernel 2.6.15-rt2-sr3. See http://www-gatago.com/linux/kernel/14664637.html I don't know if this problem has been noticed and was the reason for the old dmapi implementation but for kernel versions later than 2.6.15-rt2-sr3 your patch makes perfect sense. Thanks and regards, Vlad Kevin Jamieson wrote: > dm_create_session() calls create_proc_read_entry() with the > dm_session_lock > spinlock held. But create_proc_entry() calls kmalloc(GFP_KERNEL), > which can > sleep, so this isn't safe. > > We have observed this to cause deadlocks with multiple processes > creating/using > DMAPI sessions concurrently (this was with SLES10's 2.6.16.21-0.8 > kernel, but > the DMAPI code in question is the same in CVS HEAD): > > BUG: spinlock cpu recursion on CPU#1, a1/3235 > lock: f930c49c, .magic: dead4ead, .owner: a2/22546, .owner_cpu: 1 > > Stack traceback for pid 6144 > 0xdfc98270 6144 2748 1 0 R 0xdfc98450 a1 > EBP EIP Function (args) > 0xf0f5be24 0xc010d89f delay_tsc+0xc (0xf0f5be44) > 0xf0f5be2c 0xc01cd928 __delay+0xc (0x1, 0x18, 0xf0f5be90, 0xf0f5be8c) > 0xc01ceb85 _raw_spin_lock+0x79 > 0xf0f5be4c 0xc02afd93 _spin_lock+0x8 (0x1, 0x18, 0xf0f5be8c, 0x1) > 0xf0f5be64 0xf9307302 [dmapi]dm_find_session_and_lock+0x1a (0x2220a, 0x1, > 0x8fb5b198, 0x6f6b8864, 0xe) > 0xf0f5bea0 0xf93062eb [dmapi]dm_app_get_tdp+0x87 (0xffffffff, 0x2, 0x1, > 0xf0f5beb8, 0x3000) > 0xf0f5bec0 0xf9302cf6 [dmapi]dm_read_invis_rvp+0x17 (0xffffffff, > 0x27c4000, 0x0, 0x4000, 0x0) > 0xf0f5bf48 0xf93014b9 [dmapi]dmapi_ioctl+0x4ab (0xab0be160, 0x28, > 0xfffffff7, 0xf787f9c0, 0xab0be160) > 0xf0f5bf64 0xc01700d3 do_ioctl+0x4f (0xaf345000, 0xf6f58240, 0x1b, 0x2, > 0xaf3459ac) > 0xf0f5bf98 0xc0170346 vfs_ioctl+0x25a (0xab0be160, 0x1, 0x1b, 0x0, > 0xb7825bf0) > 0xf0f5bfb4 0xc01703a9 sys_ioctl+0x50 > 0xc0103d1b sysenter_past_esp+0x54 > > Stack traceback for pid 3254 > 0xdfec0720 3254 2748 1 1 R 0xdfec0900 *a1 > EBP EIP Function (args) > 0xf6f71e40 0xc01ce862 spin_bug (0xf66cbf20, 0xffffffda, 0xf6f71ec0, > 0xf6f71ebc) > 0xc01ceb58 _raw_spin_lock+0x4c > 0xf6f71e48 0xc02afd93 _spin_lock+0x8 (0x1, 0xffffffda, 0x0, 0xb32f01d0) > 0xf6f71e60 0xf9307302 [dmapi]dm_find_session_and_lock+0x1a (0x0, 0x1, > 0x0, > 0x0, 0x3) > 0xf6f71ed0 0xf9307538 [dmapi]dm_get_events+0x24 (0xfff, 0xad2e2ae8, > 0xb32f02c8, 0x1, 0x0) > 0xf6f71f48 0xf9301274 [dmapi]dmapi_ioctl+0x266 (0xb32f01d0, 0x12, > 0xfffffff7, 0xf787f9c0, 0xb32f01d0) > 0xf6f71f64 0xc01700d3 do_ioctl+0x4f (0x0, 0x0, 0x1b, 0xf66d31cc, > 0x8517980) > 0xf6f71f98 0xc0170346 vfs_ioctl+0x25a (0xb32f01d0, 0x1, 0x1b, 0xad2f7400, > 0xb32f02c4) > 0xf6f71fb4 0xc01703a9 sys_ioctl+0x50 > 0xc0103d1b sysenter_past_esp+0x54 > > Stack traceback for pid 12452 > 0xdfb047e0 12452 12451 0 1 R 0xdfb049c0 a2 > EBP EIP Function (args) > 0xf14cbcbc 0xc02ae254 schedule+0xb84 (0xdffff180) > 0xf14cbcc8 0xc02ae33b cond_resched+0x36 (0x0, 0x1, 0xf14cbe53) > 0xf14cbcdc 0xc015d07a __kmalloc+0x4a (0x1, 0x8124, 0xa, 0x8, 0xf14cbe48) > 0xf14cbd04 0xc018ef93 proc_create+0x8c (0x1, 0xf784d440, 0xf14cbe34, > 0xd53b5de8) > 0xf14cbd1c 0xc018f045 create_proc_entry+0x5f (0xf14cbe34, 0xf9309030, > 0xd53b5de8, 0x7, 0x61637942) > 0xf14cbedc 0xf9307c14 [dmapi]dm_create_session+0x234 (0x0, 0x0, > 0x80db388, > 0xb7fccff4, 0x82fa604) > 0xf14cbf48 0xf93010b0 [dmapi]dmapi_ioctl+0xa2 (0xbfd1fb00, 0x3, > 0xfffffff7, 0xf1399540, 0xbfd1fb00) > 0xf14cbf64 0xc01700d3 do_ioctl+0x4f (0xf54cf080, 0xf782cee4, 0x3, > 0xc02b0c16, 0x0) > 0xf14cbf98 0xc0170346 vfs_ioctl+0x25a (0xbfd1fb00, 0x0, 0x3, 0x82fa600, > 0x2) > 0xf14cbfb4 0xc01703a9 sys_ioctl+0x50 > 0xc0103d1b sysenter_past_esp+0x54 > > > It doesn't appear necessary for create/remove_proc_entry() to be > called with the > dm_session_lock spinlock held. The following patch moves these calls > outside of > the spinlock. > > > Signed-off-by: Kevin Jamieson > Index: fs/dmapi/dmapi_session.c > =================================================================== > RCS file: /cvs/linux-2.6-xfs/fs/dmapi/dmapi_session.c,v > retrieving revision 1.31 > diff -u -r1.31 dmapi_session.c > --- fs/dmapi/dmapi_session.c 12 Jan 2007 15:07:58 -0000 1.31 > +++ fs/dmapi/dmapi_session.c 16 Feb 2007 06:14:08 -0000 > @@ -519,13 +519,14 @@ > sv_init(&s->sn_readerq, SV_DEFAULT, "dmreadq"); > sv_init(&s->sn_writerq, SV_DEFAULT, "dmwritq"); > spinlock_init(&s->sn_qlock, "sn_qlock"); > - lc = mutex_spinlock(&dm_session_lock); > } else { > lc = mutex_spinlock(&dm_session_lock); > if ((error = dm_find_session(old, &s)) != 0) { > mutex_spinunlock(&dm_session_lock, lc); > return(error); > } > + unlink_session(s); > + mutex_spinunlock(&dm_session_lock, lc); > #ifdef CONFIG_PROC_FS > { > char buf[100]; > @@ -533,12 +534,13 @@ > remove_proc_entry(buf, NULL); > } > #endif > - unlink_session(s); > } > memcpy(s->sn_info, sessinfo, len); > s->sn_info[len-1] = 0; /* if not NULL, then now 'tis */ > s->sn_sessid = sid; > + lc = mutex_spinlock(&dm_session_lock); > link_session(s); > + mutex_spinunlock(&dm_session_lock, lc); > #ifdef CONFIG_PROC_FS > { > char buf[100]; > @@ -549,7 +551,6 @@ > entry->owner = THIS_MODULE; > } > #endif > - mutex_spinunlock(&dm_session_lock, lc); > return(0); > } > > @@ -583,6 +584,12 @@ > mutex_spinunlock(&dm_session_lock, lc); > return(-EBUSY); > } > + > + /* The session is not in use. Dequeue it from the session chain. */ > + > + unlink_session(s); > + nested_spinunlock(&s->sn_qlock); > + mutex_spinunlock(&dm_session_lock, lc); > > #ifdef CONFIG_PROC_FS > { > @@ -592,12 +599,6 @@ > } > #endif > > - /* The session is not in use. Dequeue it from the session chain. */ > - > - unlink_session(s); > - nested_spinunlock(&s->sn_qlock); > - mutex_spinunlock(&dm_session_lock, lc); > - > /* Now clear the sessions's disposition registration, and then > destroy > the session structure. > */ > > From owner-xfs@oss.sgi.com Sun Feb 18 18:49:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Feb 2007 18:49:57 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1J2nom7030097 for ; Sun, 18 Feb 2007 18:49:52 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07464; Mon, 19 Feb 2007 13:49:46 +1100 Message-ID: <45D91104.10601@sgi.com> Date: Mon, 19 Feb 2007 13:52:52 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: linux-xfs@oss.sgi.com Subject: TAKE 961263 -[PATCH] dm_create_session() calls create_proc_entry() with spinlock held References: <45D910C6.7060400@sgi.com> In-Reply-To: <45D910C6.7060400@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10670 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 559 Lines: 15 Date: Mon Feb 19 13:45:32 AEDT 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: vapo Author: Kevin Jamieson The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: linux-melb:dmapi:28121a fs/dmapi/dmapi_session.c - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dmapi/dmapi_session.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h - pv 961263, rv vapo - Do not hold dm_session_lock while calling create_proc_read_entry() and remove_proc_entry() From owner-xfs@oss.sgi.com Sun Feb 18 18:48:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Feb 2007 18:48:57 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1J2mom7029868 for ; Sun, 18 Feb 2007 18:48:51 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07436; Mon, 19 Feb 2007 13:48:44 +1100 Message-ID: <45D910C6.7060400@sgi.com> Date: Mon, 19 Feb 2007 13:51:50 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: linux-xfs@oss.sgi.com Subject: Subject: TAKE 961263 -[PATCH] dm_create_session() calls create_proc_entry() with spinlock held Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10669 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 561 Lines: 15 Date: Mon Feb 19 13:45:32 AEDT 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: vapo Author: Kevin Jamieson The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: linux-melb:dmapi:28121a fs/dmapi/dmapi_session.c - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dmapi/dmapi_session.c.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h - pv 961263, rv vapo - Do not hold dm_session_lock while calling create_proc_read_entry() and remove_proc_entry() From owner-xfs@oss.sgi.com Sun Feb 18 21:16:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Feb 2007 21:16:51 -0800 (PST) X-Spam-oss-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1J5Ggm7021880 for ; Sun, 18 Feb 2007 21:16:44 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA10507; Mon, 19 Feb 2007 16:16:40 +1100 Message-Id: <200702190516.QAA10507@larry.melbourne.sgi.com> From: "Barry Naujok" To: Cc: Subject: [PATCH] Cleanup some build cruft in xfs-cmds GNUmakefile Date: Mon, 19 Feb 2007 16:18:26 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0073_01C75441.965EA160" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdT5WIo/1OA7JvwSdmlVmyJvbauUQ== X-archive-position: 10671 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 2914 Lines: 93 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01C75441.965EA160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Clean up some old SGI specific stuff in the root xfs-cmds GNUmakefile, and be able to set final location for the RPM packages from the environment. ------=_NextPart_000_0073_01C75441.965EA160 Content-Type: application/octet-stream; name="makefile_clean.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="makefile_clean.patch" --- a/GNUmakefile 2007-02-19 16:13:09.000000000 +1100 +++ b/GNUmakefile 2007-02-19 16:08:42.302255319 +1100 @@ -1,16 +1,16 @@ # -# Copyright (c) 2002 Silicon Graphics, Inc. All Rights Reserved. +# Copyright (c) 2002-2007 Silicon Graphics, Inc. All Rights Reserved. # -# Top-level makefile for all of xfs-cmds (with specific bits for LBS) +# Top-level makefile for all of xfs-cmds # =20 XFS_CMDS_DIR :=3D $(shell pwd) =20 -# This is true for both LBS and 2.4.x-xfs builds... for now... -TOP=3D.. - ARCH :=3D $(shell uname -m | sed -e s/i.86/i386/) =20 +RPM_OUT_DIR ?=3D $(XFS_CMDS_DIR)/RPMS/$(ARCH) +SRPM_OUT_DIR ?=3D $(XFS_CMDS_DIR)/SRPMS + COMMANDS =3D attr acl xfsprogs dmapi xfsdump =20 # We'd like to be able to satisfy dependencies from within the @@ -50,37 +50,22 @@ ( cd $(XFS_CMDS_DIR)/$$d && ./Makepkgs ) || exit 1; \ done for d in $(COMMANDS); do \ - ( cd $(XFS_CMDS_DIR) && /bin/cp $$d/build/rpm/*.src.rpm SRPMS ) \ + ( cd $(XFS_CMDS_DIR) && /bin/cp $$d/build/rpm/*.src.rpm $(SRPM_OUT_DIR) = ) \ done for d in $(COMMANDS); do \ - ( cd $(XFS_CMDS_DIR) && /bin/cp $$d/build/rpm/*.$(ARCH).rpm RPMS/$(ARCH)= ) \ + ( cd $(XFS_CMDS_DIR) && /bin/cp $$d/build/rpm/*.$(ARCH).rpm $(RPM_OUT_DI= R) ) \ done =20 - # If this is an LBS build ($(TOP)/sgi-install/SGI/RPMS exists) - # then copy the RPMs over to sgi-install after they're built - ([ -d $(TOP)/sgi-install/SGI/RPMS ] && \ - ( /bin/cp $(XFS_CMDS_DIR)/RPMS/$(ARCH)/*.rpm $(TOP)/sgi-install/SGI/RPMS= )) || \ - echo - - ([ -d $(TOP)/sgi-install/SGI/SRPMS ] && \ - ( /bin/cp $(XFS_CMDS_DIR)/SRPMS/*.src.rpm $(TOP)/sgi-install/SGI/SRPMS )= ) || \ - echo - builddirs: echo "cmd builddirs" - ([ -d $(XFS_CMDS_DIR)/BUILD ] || mkdir $(XFS_CMDS_DIR)/BUILD) - ([ -d $(XFS_CMDS_DIR)/SRPMS ] || mkdir $(XFS_CMDS_DIR)/SRPMS) - ([ -d $(XFS_CMDS_DIR)/RPMS/$(ARCH) ] || mkdir -p $(XFS_CMDS_DIR)/RPMS/$(A= RCH)) + ([ -d $(SRPM_OUT_DIR) ] || mkdir -p $(SRPM_OUT_DIR)) + ([ -d $(RPM_OUT_DIR) ] || mkdir -p $(RPM_OUT_DIR)) =20 clean: - rm -rf RPMS SRPMS BUILD SOURCES + rm -rf $(SRPM_OUT_DIR) $(RPM_OUT_DIR) for d in $(COMMANDS); do \ ( cd $(XFS_CMDS_DIR)/$$d && make -i clean ) \ done =20 realclean: clean for d in $(COMMANDS); do ( cd $(XFS_CMDS_DIR)/$$d && make realclean ) done - -clean-lbs: realclean - -build-lbs: cmds-install ------=_NextPart_000_0073_01C75441.965EA160-- From owner-xfs@oss.sgi.com Sun Feb 18 22:25:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Feb 2007 22:26:01 -0800 (PST) X-Spam-oss-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1J6P3m7030398 for ; Sun, 18 Feb 2007 22:25:05 -0800 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA11976; Mon, 19 Feb 2007 17:24:58 +1100 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 6C7F822C4DBE; Mon, 19 Feb 2007 17:24:58 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 961225 - Fix grace time display problems in xfs_quota Message-Id: <20070219062458.6C7F822C4DBE@linuxbuild.melbourne.sgi.com> Date: Mon, 19 Feb 2007 17:24:58 +1100 (EST) X-archive-position: 10672 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Content-Length: 1212 Lines: 30 Fix grace time display problems in xfs_quota Subject: [PATCH] fix the grace time in xfs_quota Date: Thu, 15 Feb 2007 16:39:52 +0900 From: Utako Kusaka To: xfs@oss.sgi.com Hi, When a quota limit is reached at a soft limit, xfs_quota(8) shows the incorrect grace time. Because, the subtraction with '__uint32_t' and 'time_t' are done in time_to_string(), and the result does not become a negative value, but a huge value. This patch fixes it. Date: Mon Feb 19 17:19:54 AEDT 2007 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/xfs-cmds Inspected by: Utako Kusaka The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:28131a xfsprogs/doc/CHANGES - 1.235 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.235&r2=text&tr2=1.234&f=h xfsprogs/quota/quota.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/quota.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/quota/util.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/util.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h From owner-xfs@oss.sgi.com Mon Feb 19 02:53:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Feb 2007 02:53:59 -0800 (PST) X-Spam-oss-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1JArpm7009149 for ; Mon, 19 Feb 2007 02:53:53 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HJ5ot-0003eX-Tz; Mon, 19 Feb 2007 10:32:31 +0000 Date: Mon, 19 Feb 2007 10:32:31 +0000 From: Christoph Hellwig To: Barry Naujok Cc: xfs@oss.sgi.com, xfs-dev@corp.sgi.com Subject: Re: [PATCH] Cleanup some build cruft in xfs-cmds GNUmakefile Message-ID: <20070219103231.GA13906@infradead.org> References: <200702190516.QAA10507@larry.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702190516.QAA10507@larry.melbourne.sgi.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10673 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 234 Lines: 6 On Mon, Feb 19, 2007 at 04:18:26PM +1100, Barry Naujok wrote: > Clean up some old SGI specific stuff in the root xfs-cmds GNUmakefile, and > be able to set final location for the RPM packages from the environment. looks good to me. From owner-xfs@oss.sgi.com Mon Feb 19 12:26:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Feb 2007 12:26:09 -0800 (PST) X-Spam-oss-Status: No, score=0.1 required=5.0 tests=BAYES_50,J_CHICKENPOX_74 autolearn=no version=3.2.0-pre1-r497472 Received: from Perches.com (DSL022.labridge.com [206.117.136.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1JKQ1m7032046 for ; Mon, 19 Feb 2007 12:26:02 -0800 Received: from [192.168.1.128] ([192.168.1.128]) by Perches.com (8.9.3/8.9.3) with ESMTP id KAA01908 for ; Mon, 19 Feb 2007 10:43:03 -0800 Subject: [PATCH] - remove local random function, use lib/random.c random32() From: Joe Perches To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Mon, 19 Feb 2007 11:25:37 -0800 Message-Id: <1171913137.32497.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0-1mdv2007.0 Content-Transfer-Encoding: 7bit X-archive-position: 10675 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: joe@perches.com Precedence: bulk X-list: xfs Content-Length: 1978 Lines: 70 reducing the number of random number functions Signed-off-by: Joe Perches diff --git a/fs/xfs/support/debug.c b/fs/xfs/support/debug.c index 4363512..200b701 100644 --- a/fs/xfs/support/debug.c +++ b/fs/xfs/support/debug.c @@ -78,20 +78,3 @@ assfail(char *expr, char *file, int line) printk("Assertion failed: %s, file: %s, line: %d\n", expr, file, line); BUG(); } - -#if ((defined(DEBUG) || defined(INDUCE_IO_ERRROR)) && !defined(NO_WANT_RANDOM)) -unsigned long random(void) -{ - static unsigned long RandomValue = 1; - /* cycles pseudo-randomly through all values between 1 and 2^31 - 2 */ - register long rv = RandomValue; - register long lo; - register long hi; - - hi = rv / 127773; - lo = rv % 127773; - rv = 16807 * lo - 2836 * hi; - if (rv <= 0) rv += 2147483647; - return RandomValue = rv; -} -#endif /* DEBUG || INDUCE_IO_ERRROR || !NO_WANT_RANDOM */ diff --git a/fs/xfs/support/debug.h b/fs/xfs/support/debug.h index 4f54dca..2cdb4cd 100644 --- a/fs/xfs/support/debug.h +++ b/fs/xfs/support/debug.h @@ -40,7 +40,7 @@ extern void assfail(char *expr, char *f, int l); # define ASSERT(expr) ((void)0) #else # define ASSERT(expr) ASSERT_ALWAYS(expr) -extern unsigned long random(void); +# include #endif #ifndef STATIC diff --git a/fs/xfs/xfs_alloc.c b/fs/xfs/xfs_alloc.c index e80dda3..8e9a40a 100644 --- a/fs/xfs/xfs_alloc.c +++ b/fs/xfs/xfs_alloc.c @@ -764,7 +764,7 @@ xfs_alloc_ag_vextent_near( */ int dofirst; /* set to do first algorithm */ - dofirst = random() & 1; + dofirst = random32() & 1; #endif /* * Get a cursor for the by-size btree. diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c index b95681b..35df82d 100644 --- a/fs/xfs/xfs_error.c +++ b/fs/xfs/xfs_error.c @@ -80,7 +80,7 @@ xfs_error_test(int error_tag, int *fsidp, char *expression, int i; int64_t fsid; - if (random() % randfactor) + if (random32() % randfactor) return 0; memcpy(&fsid, fsidp, sizeof(xfs_fsid_t)); From owner-xfs@oss.sgi.com Mon Feb 19 15:42:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Feb 2007 15:42:42 -0800 (PST) X-Spam-oss-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1JNgYm7024609 for ; Mon, 19 Feb 2007 15:42:37 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06673; Tue, 20 Feb 2007 10:42:29 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id B9BA258CA547; Tue, 20 Feb 2007 10:42:29 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 961289 - Clean up old LBS cruft in xfs-cmds root makefile Message-Id: <20070219234229.B9BA258CA547@chook.melbourne.sgi.com> Date: Tue, 20 Feb 2007 10:42:29 +1100 (EST) From: bnaujok@sgi.com (Barry Naujok) X-archive-position: 10676 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Content-Length: 527 Lines: 17 Remove old SGI build stuff from root makefile. Date: Tue Feb 20 10:41:45 AEDT 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:28135a GNUmakefile - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/GNUmakefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - Remove old SGI build stuff and set final RPM location from the environment. From owner-xfs@oss.sgi.com Mon Feb 19 19:31:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Feb 2007 19:31:32 -0800 (PST) X-Spam-oss-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1K3VNm7032103 for ; Mon, 19 Feb 2007 19:31:25 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12863; Tue, 20 Feb 2007 14:31:15 +1100 Date: Tue, 20 Feb 2007 14:31:58 +1100 From: Timothy Shimmin To: Linda Walsh , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: lock checking feedback (bug?) 2.6.20(xfs)/i386 during boot Message-ID: <12954EC2E224B896D61E6A34@timothy-shimmins-power-mac-g5.local> In-Reply-To: <45D8C765.7080306@tlinx.org> References: <45D8C765.7080306@tlinx.org> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 10677 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 3451 Lines: 91 Thanks for the report, Linda. This and other lockdep reports are on our todo/bug list and I've added this one. (Nathan looked at some of these lock related changes I believe and we still have a pending patch of his to go thru) --Tim --On 18 February 2007 1:38:45 PM -0800 Linda Walsh wrote: > Turned on lock testing/proving/deadlock detection. Not chasing any particular > problem, but looking for things "oddities". > > Turned on options (under kernel hacking): > Locking API boot-time self-tests > RT Mutex debugging, deadlock detection > Lock debugging: prove locking correctness > > Multiple reboots show it to be a constant. > I had tried the new "Asynchronous SCSI scanning" -- thought that might have been > related, but turning it off makes no difference. > > I'm guessing this "error" has been present before this, but the lock > proving algorithms are bringing it to light? So I don't know how serious > this is (if it is anything), but at the least, it doesn't look too clean... > > > Maybe that > .... > SCSI device sda: write cache: enabled, read cache: enabled, supports DPO and FUA > sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 > > sd 0:0:0:0: Attached scsi disk sda > UDF-fs: No VRS found > XFS mounting filesystem sda3 > Ending clean XFS mount for filesystem: sda3 > VFS: Mounted root (xfs filesystem) readonly. > Freeing unused kernel memory: 316k freed > > ============================================= > [ INFO: possible recursive locking detected ] > 2.6.20 #3 > --------------------------------------------- > rm/682 is trying to acquire lock: > (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x7d/0xb0 > > but task is already holding lock: > (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x7d/0xb0 > > other info that might help us debug this: > 3 locks held by rm/682: > #0: (&inode->i_mutex/1){--..}, at: [] do_unlinkat+0x96/0x170 > #1: (&inode->i_mutex){--..}, at: [] vfs_unlink+0x5a/0xd0 > #2: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x7d/0xb0 > > stack backtrace: > [] __lock_acquire+0xaf1/0xdf0 > [] lock_acquire+0x57/0x70 > [] xfs_ilock+0x7d/0xb0 > [] down_write+0x2f/0x50 > [] xfs_ilock+0x7d/0xb0 > [] xfs_ilock+0x7d/0xb0 > [] xfs_lock_dir_and_entry+0xfd/0x100 > [] xfs_remove+0x198/0x4e0 > [] xfs_access+0x26/0x50 > [] xfs_access+0x26/0x50 > [] vfs_unlink+0x5a/0xd0 > [] xfs_vn_unlink+0x23/0x60 > [] __mutex_lock_slowpath+0x152/0x2a0 > [] mark_held_locks+0x6b/0x90 > [] __mutex_lock_slowpath+0x152/0x2a0 > [] __mutex_lock_slowpath+0x152/0x2a0 > [] trace_hardirqs_on+0xc7/0x170 > [] __mutex_lock_slowpath+0x145/0x2a0 > [] vfs_unlink+0x5a/0xd0 > [] permission+0x137/0x140 > [] vfs_unlink+0x90/0xd0 > [] do_unlinkat+0xd3/0x170 > [] do_page_fault+0x327/0x630 > [] sysenter_past_esp+0x5f/0x99 > ======================= > XFS mounting filesystem sda1 > Ending clean XFS mount for filesystem: sda1 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-xfs@oss.sgi.com Mon Feb 19 23:53:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Feb 2007 23:53:09 -0800 (PST) X-Spam-oss-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1K7r2m7002259 for ; Mon, 19 Feb 2007 23:53:04 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18328; Tue, 20 Feb 2007 18:53:01 +1100 Message-Id: <200702200753.SAA18328@larry.melbourne.sgi.com> From: "Barry Naujok" To: Cc: Subject: [PATCH] fix bad quota inodes in the superblock causing xfs_repair to crash Date: Tue, 20 Feb 2007 18:59:12 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E7_01C75521.35B7D3F0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdUxQHU5S69ZrcKTfu1Zzy+5b+lCA== X-archive-position: 10678 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 2268 Lines: 64 This is a multi-part message in MIME format. ------=_NextPart_000_00E7_01C75521.35B7D3F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks to Eric for generating bad images with fsfuzzer, bad quota inode values in the superblock caused xfs_repair to segfault. The patch checks the validity of the inodes before doing an internal lookup which assumes the numbers are valid before being called. ------=_NextPart_000_00E7_01C75521.35B7D3F0 Content-Type: application/octet-stream; name="bad_quota_ino_crash.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="bad_quota_ino_crash.diff" --- a/xfsprogs/repair/phase4.c 2007-02-20 18:50:18.000000000 +1100 +++ b/xfsprogs/repair/phase4.c 2007-02-20 18:42:00.764536317 +1100 @@ -1059,8 +1059,12 @@ quotino_check(xfs_mount_t *mp) ino_tree_node_t *irec; =20 if (mp->m_sb.sb_uquotino !=3D NULLFSINO && mp->m_sb.sb_uquotino !=3D 0) { - irec =3D find_inode_rec(XFS_INO_TO_AGNO(mp, mp->m_sb.sb_uquotino), - XFS_INO_TO_AGINO(mp, mp->m_sb.sb_uquotino)); + if (verify_inum(mp, mp->m_sb.sb_uquotino)) + irec =3D NULL; + else + irec =3D find_inode_rec( + XFS_INO_TO_AGNO(mp, mp->m_sb.sb_uquotino), + XFS_INO_TO_AGINO(mp, mp->m_sb.sb_uquotino)); =20 if (irec =3D=3D NULL || is_inode_free(irec, mp->m_sb.sb_uquotino - irec->ino_startnum)) { @@ -1071,8 +1075,12 @@ quotino_check(xfs_mount_t *mp) } =20 if (mp->m_sb.sb_gquotino !=3D NULLFSINO && mp->m_sb.sb_gquotino !=3D 0) { - irec =3D find_inode_rec(XFS_INO_TO_AGNO(mp, mp->m_sb.sb_gquotino), - XFS_INO_TO_AGINO(mp, mp->m_sb.sb_gquotino)); + if (verify_inum(mp, mp->m_sb.sb_gquotino)) + irec =3D NULL; + else + irec =3D find_inode_rec( + XFS_INO_TO_AGNO(mp, mp->m_sb.sb_gquotino), + XFS_INO_TO_AGINO(mp, mp->m_sb.sb_gquotino)); =20 if (irec =3D=3D NULL || is_inode_free(irec, mp->m_sb.sb_gquotino - irec->ino_startnum)) { @@ -1322,7 +1330,7 @@ phase4(xfs_mount_t *mp) /* * now reset the bitmap for all ags */ - bzero(ba_bmap[i],=20 + bzero(ba_bmap[i], roundup((mp->m_sb.sb_agblocks+(NBBY/XR_BB)-1)/(NBBY/XR_BB), sizeof(__uint64_t))); for (j =3D 0; j < ag_hdr_block; j++) ------=_NextPart_000_00E7_01C75521.35B7D3F0-- From owner-xfs@oss.sgi.com Tue Feb 20 06:16:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 06:16:45 -0800 (PST) X-Spam-oss-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_56,J_CHICKENPOX_62 autolearn=no version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1KEGZm7030989 for ; Tue, 20 Feb 2007 06:16:38 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 62CD914A891 for ; Tue, 20 Feb 2007 16:21:14 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XVMCPRS-r8v7 for ; Tue, 20 Feb 2007 16:21:14 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 2B52C1C9C6 for ; Tue, 20 Feb 2007 16:21:14 +0200 (IST) From: "Leon Kolchinsky" To: Subject: xfsdump/xfsrestore question Date: Tue, 20 Feb 2007 16:16:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdU+be/qh0tJbRcS26e9PUNIcvlpg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070220142114.2B52C1C9C6@mail.edu.haifa.ac.il> X-archive-position: 10679 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 1592 Lines: 59 Hello All, I have a question about xfsdump/xfsrestore usage on Linux. I'm running Linux 2.6.19-gentoo-r5. Now I have 2 disks, /dev/hda is my system disk /dev/hdc is a disk I want to use for backups. This is how my fstab looks like: /dev/hda1 / xfs noatime,nodiratime,logbufs=8 1 1 /dev/hda2 none swap sw 0 0 /dev/hdc3 /var/tmp/portage xfs noatime,nodiratime,logbufs=8 0 0 /dev/hdc2 /data xfs noatime,nodiratime,logbufs=8 0 0 /dev/hdc1 none swap sw 0 0 /dev/cdrom /mnt/cdrom iso9660 noauto,ro 0 0 /dev/fd0 /mnt/floppy auto noauto 0 0 # NOTE: The next line is critical for boot! proc /proc proc defaults 0 0 shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 ######################################## Now the questions: 1) If I get the xfsdump synax correctly I just have to do: # cd / # xfsdump -f /data/backup.file / Is it right? What about opened and "currently in use by the system" files? Are they backuped in a proper way? What about tmpfs like /proc, are they been ignored? 2) If I'd have to restore my system from the dump, how would you recommend to do it? Booting from LiveCD and making # xfsrestore -f / data/backup.file / ? Would it be a bootable/operational system? What are the expected glitches? Best Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Tue Feb 20 06:20:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 06:20:09 -0800 (PST) X-Spam-oss-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_56,J_CHICKENPOX_62,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r497472 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1KEK1m7031847 for ; Tue, 20 Feb 2007 06:20:03 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id 4A5B51A000FC4; Tue, 20 Feb 2007 09:19:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 447B1A000874; Tue, 20 Feb 2007 09:19:55 -0500 (EST) Date: Tue, 20 Feb 2007 09:19:55 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Leon Kolchinsky cc: xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore question In-Reply-To: <20070220142114.2B52C1C9C6@mail.edu.haifa.ac.il> Message-ID: References: <20070220142114.2B52C1C9C6@mail.edu.haifa.ac.il> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 10680 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 2053 Lines: 74 On Tue, 20 Feb 2007, Leon Kolchinsky wrote: > Hello All, > > I have a question about xfsdump/xfsrestore usage on Linux. > > I'm running Linux 2.6.19-gentoo-r5. > > Now I have 2 disks, > /dev/hda is my system disk > /dev/hdc is a disk I want to use for backups. > > This is how my fstab looks like: > > /dev/hda1 / xfs > noatime,nodiratime,logbufs=8 1 1 > /dev/hda2 none swap sw > 0 0 > /dev/hdc3 /var/tmp/portage xfs > noatime,nodiratime,logbufs=8 0 0 > /dev/hdc2 /data xfs > noatime,nodiratime,logbufs=8 0 0 > /dev/hdc1 none swap sw > 0 0 > /dev/cdrom /mnt/cdrom iso9660 noauto,ro > 0 0 > /dev/fd0 /mnt/floppy auto noauto > 0 0 > > # NOTE: The next line is critical for boot! > proc /proc proc defaults 0 0 > > shm /dev/shm tmpfs nodev,nosuid,noexec > 0 0 > > ######################################## > > Now the questions: > > 1) If I get the xfsdump synax correctly I just have to do: > > # cd / > # xfsdump -f /data/backup.file / > > Is it right? > What about opened and "currently in use by the system" files? Are they > backuped in a proper way? What about tmpfs like /proc, are they been > ignored? > > 2) If I'd have to restore my system from the dump, how would you recommend > to do it? Booting from LiveCD and making # xfsrestore -f / data/backup.file > / ? > > Would it be a bootable/operational system? > What are the expected glitches? > > > Best Regards, > Leon Kolchinsky > > > This generally looks correct, there are some options to name the tape/ID of the backup itself, you can specify them on the command line. For ignoring certain paths, yes this works as well, you can chattr I believe (check the manpage) certain directories / files and they will be ignored by xfsdump. Justin. From owner-xfs@oss.sgi.com Tue Feb 20 06:35:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 06:35:42 -0800 (PST) X-Spam-oss-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_05, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1KEZYm7001644 for ; Tue, 20 Feb 2007 06:35:35 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E65CC1802EE19; Tue, 20 Feb 2007 08:35:33 -0600 (CST) Message-ID: <45DB0734.4060707@sandeen.net> Date: Tue, 20 Feb 2007 08:35:32 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Barry Naujok CC: xfs@oss.sgi.com, xfs-dev@corp.sgi.com Subject: Re: [PATCH] fix bad quota inodes in the superblock causing xfs_repair to crash References: <200702200753.SAA18328@larry.melbourne.sgi.com> In-Reply-To: <200702200753.SAA18328@larry.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10681 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 392 Lines: 12 Barry Naujok wrote: > Thanks to Eric for generating bad images with fsfuzzer, bad quota inode > values in the superblock caused xfs_repair to segfault. The patch checks the > validity of the inodes before doing an internal lookup which assumes the > numbers are valid before being called. > Looks good to me Barry, thanks! I'll see if I can find more corrupt images for you. ;-) -Eric From owner-xfs@oss.sgi.com Tue Feb 20 11:13:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 11:13:24 -0800 (PST) X-Spam-oss-Status: No, score=3.1 required=5.0 tests=BAYES_80,J_CHICKENPOX_43, SPF_HELO_PASS,WHOIS_MYPRIVREG autolearn=no version=3.2.0-pre1-r497472 Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1KJDKm7005749 for ; Tue, 20 Feb 2007 11:13:21 -0800 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HJa9v-0002ZF-Tn for linux-xfs@oss.sgi.com; Tue, 20 Feb 2007 10:56:15 -0800 Message-ID: <9068053.post@talk.nabble.com> Date: Tue, 20 Feb 2007 10:56:15 -0800 (PST) From: pgf111000 To: linux-xfs@oss.sgi.com Subject: mkfs.xfs, lvm, multi-terrabyte hardware array and luks MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: junkmail@petergfrazier.com X-archive-position: 10683 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: junkmail@petergfrazier.com Precedence: bulk X-list: xfs Content-Length: 563 Lines: 15 When I try to format partitions above 2-3gb my opteron experiences heavy io wait; the mkfs.xfs fails, and I receive the following.... "mkfs.xfs: libxfs_device_zero write failed: Input/output error" When I format partions below 2-3gb, there is no problem whatsoever. I can mkfs.xfs on a +2-3GB non-luks formated partition without a problem... any thoughts? -- View this message in context: http://www.nabble.com/mkfs.xfs%2C-lvm%2C-multi-terrabyte-hardware-array-and-luks-tf3262532.html#a9068053 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Tue Feb 20 11:34:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 11:34:39 -0800 (PST) X-Spam-oss-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_43,J_CHICKENPOX_52,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r497472 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1KJYWm7008598 for ; Tue, 20 Feb 2007 11:34:34 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1KJYWri032539; Tue, 20 Feb 2007 14:34:32 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1KJYVKu012332; Tue, 20 Feb 2007 14:34:31 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1KJYVwJ015649; Tue, 20 Feb 2007 14:34:31 -0500 Message-ID: <45DB4CE1.3040302@sandeen.net> Date: Tue, 20 Feb 2007 13:32:49 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: pgf111000 CC: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs, lvm, multi-terrabyte hardware array and luks References: <9068053.post@talk.nabble.com> In-Reply-To: <9068053.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10684 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 844 Lines: 25 pgf111000 wrote: > When I try to format partitions above 2-3gb my opteron experiences heavy io > wait; the mkfs.xfs fails, and I receive the following.... > > "mkfs.xfs: libxfs_device_zero write failed: Input/output error" > > When I format partions below 2-3gb, there is no problem whatsoever. I can > mkfs.xfs on a +2-3GB non-luks formated partition without a problem... any > thoughts? Sounds like a LUKS problem, maybe it can't do those large offsets? xfs certainly can... I bet you'll find that the 2GB size is the threshold... xfs is just trying a write(): if ((bytes = write(fd, z, bytes)) < 0) { fprintf(stderr, _("%s: %s write failed: %s\n"), progname, __FUNCTION__, strerror(errno)); maybe try a simple dd write at the end of your large luks device, see how that goes. -Eric From owner-xfs@oss.sgi.com Tue Feb 20 12:00:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 12:00:58 -0800 (PST) X-Spam-oss-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_60, J_CHICKENPOX_43,J_CHICKENPOX_52,SPF_HELO_PASS,WHOIS_MYPRIVREG autolearn=no version=3.2.0-pre1-r497472 Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1KK0pm7012688 for ; Tue, 20 Feb 2007 12:00:52 -0800 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HJbAR-0000Ek-Jk for linux-xfs@oss.sgi.com; Tue, 20 Feb 2007 12:00:51 -0800 Message-ID: <9069238.post@talk.nabble.com> Date: Tue, 20 Feb 2007 12:00:51 -0800 (PST) From: pgf111000 To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs, lvm, multi-terrabyte hardware array and luks In-Reply-To: <45DB4CE1.3040302@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: junkmail@petergfrazier.com References: <9068053.post@talk.nabble.com> <45DB4CE1.3040302@sandeen.net> X-archive-position: 10685 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: junkmail@petergfrazier.com Precedence: bulk X-list: xfs Content-Length: 1443 Lines: 45 Thank you for the quick response. I have posted on a few luks forums to try to delve into this issue a little deeper; if they are aware of a resolution I'll make sure to post it. The interesting thing is that when I mkfs.ext3 on luks partitions above 2-3gb all is fine; I wish xfs and luks would play nice..... Eric Sandeen-3 wrote: > > pgf111000 wrote: >> When I try to format partitions above 2-3gb my opteron experiences heavy >> io >> wait; the mkfs.xfs fails, and I receive the following.... >> >> "mkfs.xfs: libxfs_device_zero write failed: Input/output error" >> >> When I format partions below 2-3gb, there is no problem whatsoever. I >> can >> mkfs.xfs on a +2-3GB non-luks formated partition without a problem... any >> thoughts? > > Sounds like a LUKS problem, maybe it can't do those large offsets? xfs > certainly can... > > I bet you'll find that the 2GB size is the threshold... xfs is just > trying a write(): > > if ((bytes = write(fd, z, bytes)) < 0) { > fprintf(stderr, _("%s: %s write failed: %s\n"), > progname, __FUNCTION__, strerror(errno)); > > maybe try a simple dd write at the end of your large luks device, see > how that goes. > > -Eric > > > > -- View this message in context: http://www.nabble.com/mkfs.xfs%2C-lvm%2C-multi-terrabyte-hardware-array-and-luks-tf3262532.html#a9069238 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Tue Feb 20 13:00:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 13:00:08 -0800 (PST) X-Spam-oss-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_43,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r497472 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1KL02m7025858 for ; Tue, 20 Feb 2007 13:00:03 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1KL01Ca015907; Tue, 20 Feb 2007 16:00:02 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1KL01g3011660; Tue, 20 Feb 2007 16:00:01 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1KL00EZ026501; Tue, 20 Feb 2007 16:00:00 -0500 Message-ID: <45DB60E9.5040809@sandeen.net> Date: Tue, 20 Feb 2007 14:58:17 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: pgf111000 CC: linux-xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs, lvm, multi-terrabyte hardware array and luks References: <9068053.post@talk.nabble.com> <45DB4CE1.3040302@sandeen.net> <9069238.post@talk.nabble.com> In-Reply-To: <9069238.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10687 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 727 Lines: 17 pgf111000 wrote: > Thank you for the quick response. I have posted on a few luks forums to try > to delve into this issue a little deeper; if they are aware of a resolution > I'll make sure to post it. The interesting thing is that when I mkfs.ext3 > on luks partitions above 2-3gb all is fine; I wish xfs and luks would play > nice..... mkfs.xfs actually does writes out at the end of the device and verifies them; I'm not sure ext3 is doing the same. You may find yourself in trouble on ext3 post-mkfs (or you may not...) I seem to recall that xfs has shaken out similar problems on other block devices for this reason. I'd do some simple device-level read/write tests around 2GB just for fun, see how it goes. -Eric From owner-xfs@oss.sgi.com Tue Feb 20 16:06:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 16:06:29 -0800 (PST) X-Spam-oss-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1L06Mm7022159 for ; Tue, 20 Feb 2007 16:06:24 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12273; Wed, 21 Feb 2007 11:06:15 +1100 Date: Wed, 21 Feb 2007 11:07:01 +1100 From: Timothy Shimmin To: Leon Kolchinsky , xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore question Message-ID: <80FFF742E8A3FFB101CF1455@timothy-shimmins-power-mac-g5.local> In-Reply-To: <20070220142114.2B52C1C9C6@mail.edu.haifa.ac.il> References: <20070220142114.2B52C1C9C6@mail.edu.haifa.ac.il> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 10688 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 1983 Lines: 53 Hi, --On 20 February 2007 4:16:31 PM +0200 Leon Kolchinsky wrote: > Hello All, > > I have a question about xfsdump/xfsrestore usage on Linux. > > Now the questions: > > 1) If I get the xfsdump synax correctly I just have to do: > ># cd / ># xfsdump -f /data/backup.file / > > Is it right? > What about opened and "currently in use by the system" files? Are they > backuped in a proper way? What about tmpfs like /proc, are they been > ignored? > Yes, the dump line looks reasonable (since /data is a different filesystem). As Justin mentioned the dump wants a couple of ids (session-id, media-id) which will be prompted for or you can specify then as command arguments. >From the file xfsdump/doc/README.xfsdump: 1. Dumping a filesystem to a dump file: xfsdump -f dump_file -L session_label -M media_label file_system e.g. xfsdump -f ./mydump -L 'session1' -M 'media1" /mnt/xfs0 Yes it is meant to handle a changing filesystem - you do see warning msgs sometimes because it can't see a particular inode anymore, which can happen as we do multiple scans of the inodes and if they get deleted then it obviously can't do anything with it anymore or if the inode is reused as a dir instead of a reg-file etc... It won't dump out foreign filesystems mounted under / because it doesn't actually do a directory walk to dump data but actually iterates through all the inodes of the filesystem (using an xfs ioctl called bulkstat) (and for a directory inode it will just dump out the dirents). It won't dump out /var/lib/xfsdump which contains the dump inventory which is used for info for incremental dumps and resumed dumps. > 2) If I'd have to restore my system from the dump, how would you recommend > to do it? Booting from LiveCD and making # xfsrestore -f / data/backup.file > / ? > Booting from a filesystem other than the one your are restoring to - yes:) > Would it be a bootable/operational system? Should be. (Try it out:) --Tim From owner-xfs@oss.sgi.com Tue Feb 20 16:32:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 16:32:22 -0800 (PST) X-Spam-oss-Status: No, score=3.7 required=5.0 tests=AWL,BAYES_99, J_CHICKENPOX_43,J_CHICKENPOX_52,SPF_HELO_PASS,WHOIS_MYPRIVREG autolearn=no version=3.2.0-pre1-r497472 Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1L0WHm7031904 for ; Tue, 20 Feb 2007 16:32:18 -0800 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HJfP7-00087L-5X for linux-xfs@oss.sgi.com; Tue, 20 Feb 2007 16:32:17 -0800 Message-ID: <9073464.post@talk.nabble.com> Date: Tue, 20 Feb 2007 16:32:17 -0800 (PST) From: pgf111000 To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs, lvm, multi-terrabyte hardware array and luks In-Reply-To: <9069238.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: junkmail@petergfrazier.com References: <9068053.post@talk.nabble.com> <45DB4CE1.3040302@sandeen.net> <9069238.post@talk.nabble.com> X-archive-position: 10689 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: junkmail@petergfrazier.com Precedence: bulk X-list: xfs Content-Length: 2785 Lines: 75 Eric thanks for the help. It seems that you are likely correct in regard to the LUKS 2gb threshold. I am in the process of urandoming (via dd) a large [20gb] LUKS based ext3 partition to see if the writes fail while less than 20gb... I haven't gotten the results yet... because it takes forever. If this fails to fill the 20gb ext3 with random data then it would be fair to conclude that LUKS has a problem with large partitions [and ext3 has a problem verifying the underlying partition size], right? In the meantime I have executed a few trial and error tests (by creating various sized lv/LUKS partitions and then mkfs.xfs on them); the results overwhelming suggest that there is a 2gb xfs limitation on LUKS partitions (probably more politically correct to say it the other way around). Besides relying on LUKS forums are there any other resources that you know of that/who would/could provide a quick solution? Is there anyway that lvm2 could be contributing to this problem? Are there any mkfs.xfs commands that I must issue in this [lvm2/LUKS/Large hardware raid6 array] environment? Are there certain properties that must remain congruent in regard to the raid array, the lvm2 environment, LUKS and/or XFS? Again, thanks for your time and help. pgf111000 wrote: > > Thank you for the quick response. I have posted on a few luks forums to > try to delve into this issue a little deeper; if they are aware of a > resolution I'll make sure to post it. The interesting thing is that when > I mkfs.ext3 on luks partitions above 2-3gb all is fine; I wish xfs and > luks would play nice..... > > > Eric Sandeen-3 wrote: >> >> pgf111000 wrote: >>> When I try to format partitions above 2-3gb my opteron experiences heavy >>> io >>> wait; the mkfs.xfs fails, and I receive the following.... >>> >>> "mkfs.xfs: libxfs_device_zero write failed: Input/output error" >>> >>> When I format partions below 2-3gb, there is no problem whatsoever. I >>> can >>> mkfs.xfs on a +2-3GB non-luks formated partition without a problem... >>> any >>> thoughts? >> >> Sounds like a LUKS problem, maybe it can't do those large offsets? xfs >> certainly can... >> >> I bet you'll find that the 2GB size is the threshold... xfs is just >> trying a write(): >> >> if ((bytes = write(fd, z, bytes)) < 0) { >> fprintf(stderr, _("%s: %s write failed: %s\n"), >> progname, __FUNCTION__, strerror(errno)); >> >> maybe try a simple dd write at the end of your large luks device, see >> how that goes. >> >> -Eric >> >> >> >> > > -- View this message in context: http://www.nabble.com/mkfs.xfs%2C-lvm%2C-multi-terrabyte-hardware-array-and-luks-tf3262532.html#a9073464 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Tue Feb 20 18:00:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 18:00:21 -0800 (PST) X-Spam-oss-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50, MIME_QP_LONG_LINE autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1L20Cm7014680 for ; Tue, 20 Feb 2007 18:00:15 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA15545; Wed, 21 Feb 2007 13:00:11 +1100 Message-Id: <200702210200.NAA15545@larry.melbourne.sgi.com> From: "Barry Naujok" To: Cc: Subject: [PATCH] make sure xfs_repair doesn't restore corrupted primary superblock Date: Wed, 21 Feb 2007 13:05:22 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_013C_01C755B8.F2097D00" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdVXL5bp6HFbdWHRjesgrZ4y7AHAA== X-archive-position: 10690 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 4370 Lines: 113 This is a multi-part message in MIME format. ------=_NextPart_000_013C_01C755B8.F2097D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Phase 2 in xfs_repair fixes corrupted superblock fields, but in phase 5, the originally read primary superblock before the phase 2 fix is written to disk with updated counters. The patch in scan.c makes sure the mount point superblock copy is updated if the primary superblock is modified. Included is some fixes to libxfs when IO_DEBUG is enabled. ------=_NextPart_000_013C_01C755B8.F2097D00 Content-Type: application/octet-stream; name="update_mp_superblock.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="update_mp_superblock.diff" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xfsprogs/libxfs/rdwr.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=3D=3D=3D=3D=3D=3D=3D=3D --- a/xfsprogs/libxfs/rdwr.c 2007-02-21 12:57:29.000000000 +1100 +++ b/xfsprogs/libxfs/rdwr.c 2007-02-21 11:55:46.529075152 +1100 @@ -305,8 +305,9 @@ libxfs_getbuf(dev_t device, xfs_daddr_t=20 =20 if (cache_node_get(libxfs_bcache, &key, (struct cache_node **)&bp)) { #ifdef IO_DEBUG - fprintf(stderr, "%s: allocated buffer, key=3D%llu(%llu), %p\n", - __FUNCTION__, BBTOB(len), LIBXFS_BBTOOFF64(blkno), blkno, buf); + fprintf(stderr, "%s: allocated %ubytes buffer, key=3D%llu(%llu), %p\n", + __FUNCTION__, BBTOB(len), + (long long)LIBXFS_BBTOOFF64(blkno), (long long)blkno, bp); #endif libxfs_initbuf(bp, device, blkno, bytes); } @@ -354,7 +355,7 @@ libxfs_readbufr(dev_t dev, xfs_daddr_t b } #ifdef IO_DEBUG fprintf(stderr, "readbufr read %ubytes, blkno=3D%llu(%llu), %p\n", - bytes, LIBXFS_BBTOOFF64(blkno), blkno, bp); + bytes, (long long)LIBXFS_BBTOOFF64(blkno), (long long)blkno, bp); #endif if (bp->b_dev =3D=3D dev && bp->b_blkno =3D=3D blkno && @@ -403,7 +404,8 @@ libxfs_writebufr(xfs_buf_t *bp) } #ifdef IO_DEBUG fprintf(stderr, "writebufr wrote %ubytes, blkno=3D%llu(%llu), %p\n", - bp->b_bcount, LIBXFS_BBTOOFF64(bp->b_blkno), bp->b_blkno, bp); + bp->b_bcount, (long long)LIBXFS_BBTOOFF64(bp->b_blkno), + (long long)bp->b_blkno, bp); #endif bp->b_flags |=3D LIBXFS_B_UPTODATE; bp->b_flags &=3D ~(LIBXFS_B_DIRTY | LIBXFS_B_EXIT); @@ -432,7 +434,7 @@ libxfs_iomove(xfs_buf_t *bp, uint boff,=20 if (boff + len > bp->b_bcount) { fprintf(stderr, "Badness, iomove out of range!\n" "bp=3D(bno %llu, bytes %u) range=3D(boff %u, bytes %u)\n", - bp->b_blkno, bp->b_bcount, boff, len); + (long long)bp->b_blkno, bp->b_bcount, boff, len); abort(); } #endif @@ -464,7 +466,7 @@ libxfs_bcache_purge(void) cache_purge(libxfs_bcache); } =20 -void=20 +void libxfs_bcache_flush(void) { cache_flush(libxfs_bcache); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D xfsprogs/repair/scan.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=3D=3D=3D=3D=3D=3D=3D=3D --- a/xfsprogs/repair/scan.c 2007-02-21 12:57:29.000000000 +1100 +++ b/xfsprogs/repair/scan.c 2007-02-21 12:57:26.280306519 +1100 @@ -431,7 +431,7 @@ _("out-of-order bmap key (file offset) i } =20 /* - * If we're the last node at our level, check that the last child=20 + * If we're the last node at our level, check that the last child * block's forward sibling pointer is NULL. */ if (check_dups =3D=3D 0 && @@ -1295,6 +1295,8 @@ scan_ag( ASSERT(sb_dirty =3D=3D 0 || (sb_dirty && !no_modify)); =20 if (sb_dirty && !no_modify) { + if (agno =3D=3D 0) + memcpy(&mp->m_sb, sb, sizeof(xfs_sb_t)); libxfs_xlate_sb(XFS_BUF_PTR(sbbuf), sb, -1, XFS_SB_ALL_BITS); libxfs_writebuf(sbbuf, 0); } else ------=_NextPart_000_013C_01C755B8.F2097D00-- From owner-xfs@oss.sgi.com Tue Feb 20 18:50:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 18:50:31 -0800 (PST) X-Spam-oss-Status: No, score=2.7 required=5.0 tests=AWL,BAYES_60, J_CHICKENPOX_43,SPF_HELO_PASS,WHOIS_MYPRIVREG autolearn=no version=3.2.0-pre1-r497472 Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1L2oQm7022900 for ; Tue, 20 Feb 2007 18:50:26 -0800 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HJhYo-0007GA-3r for linux-xfs@oss.sgi.com; Tue, 20 Feb 2007 18:50:26 -0800 Message-ID: <9074554.post@talk.nabble.com> Date: Tue, 20 Feb 2007 18:50:25 -0800 (PST) From: pgf111000 To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] mkfs.xfs, lvm, multi-terrabyte hardware array and luks In-Reply-To: <45DB60E9.5040809@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: junkmail@petergfrazier.com References: <9068053.post@talk.nabble.com> <45DB4CE1.3040302@sandeen.net> <9069238.post@talk.nabble.com> <45DB60E9.5040809@sandeen.net> X-archive-position: 10691 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: junkmail@petergfrazier.com Precedence: bulk X-list: xfs Content-Length: 1812 Lines: 54 XFS.. HERE I COME!!!!!!! The LUKS partition was indeed the culprit. The LUKS partition was not accurately representing the size of the underlying logical volume (when over 2gb) automatically; in order to handle partitions over 2gb it is necessary to explicitly specify the desired size of the LUKS partition (size > pgf111000 wrote: >> Thank you for the quick response. I have posted on a few luks forums to >> try >> to delve into this issue a little deeper; if they are aware of a >> resolution >> I'll make sure to post it. The interesting thing is that when I >> mkfs.ext3 >> on luks partitions above 2-3gb all is fine; I wish xfs and luks would >> play >> nice..... > > mkfs.xfs actually does writes out at the end of the device and verifies > them; I'm not sure ext3 is doing the same. You may find yourself in > trouble on ext3 post-mkfs (or you may not...) I seem to recall that xfs > has shaken out similar problems on other block devices for this reason. > > I'd do some simple device-level read/write tests around 2GB just for > fun, see how it goes. > > -Eric > > > > -- View this message in context: http://www.nabble.com/mkfs.xfs%2C-lvm%2C-multi-terrabyte-hardware-array-and-luks-tf3262532.html#a9074554 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Tue Feb 20 20:04:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 20:04:19 -0800 (PST) X-Spam-oss-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1L44Bm7032553 for ; Tue, 20 Feb 2007 20:04:14 -0800 Received: from edge (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 54C8CAACC84; Wed, 21 Feb 2007 14:47:07 +1100 (EST) Subject: Re: [PATCH] make sure xfs_repair doesn't restore corrupted primary superblock From: Nathan Scott Reply-To: nscott@aconex.com To: Barry Naujok Cc: xfs@oss.sgi.com, xfs-dev@sgi.com In-Reply-To: <200702210200.NAA15545@larry.melbourne.sgi.com> References: <200702210200.NAA15545@larry.melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Wed, 21 Feb 2007 15:06:45 +1100 Message-Id: <1172030805.26078.169.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 10692 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 449 Lines: 13 On Wed, 2007-02-21 at 13:05 +1100, Barry Naujok wrote: > Phase 2 in xfs_repair fixes corrupted superblock fields, but in phase 5, the > originally read primary superblock before the phase 2 fix is written to disk > with updated counters. The patch in scan.c makes sure the mount point > superblock copy is updated if the primary superblock is modified. > > Included is some fixes to libxfs when IO_DEBUG is enabled. Looks good to me. -- Nathan From owner-xfs@oss.sgi.com Tue Feb 20 22:48:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 22:48:57 -0800 (PST) X-Spam-oss-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1L6mpm7027870 for ; Tue, 20 Feb 2007 22:48:53 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA22056; Wed, 21 Feb 2007 17:48:46 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id A36C658CA547; Wed, 21 Feb 2007 17:48:46 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 961299 - xfs_repair crashes in phase4 with an fsfuzzer'd image Message-Id: <20070221064846.A36C658CA547@chook.melbourne.sgi.com> Date: Wed, 21 Feb 2007 17:48:46 +1100 (EST) From: bnaujok@sgi.com (Barry Naujok) X-archive-position: 10693 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Content-Length: 534 Lines: 17 Verify quota inodes before looking them up Date: Wed Feb 21 17:47:48 AEDT 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: Eric Sandeen [sandeen@sandeen.net] The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:28152a xfsprogs/repair/phase4.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase4.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h - Verify quota inodes before looking them up From owner-xfs@oss.sgi.com Tue Feb 20 22:55:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Feb 2007 22:56:00 -0800 (PST) X-Spam-oss-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1L6tsm7030026 for ; Tue, 20 Feb 2007 22:55:56 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA22175; Wed, 21 Feb 2007 17:55:50 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 572BD58CA547; Wed, 21 Feb 2007 17:55:50 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 961339 - xfs_repair - phase5 restores corrupted superblock that was fixed in phase2 Message-Id: <20070221065550.572BD58CA547@chook.melbourne.sgi.com> Date: Wed, 21 Feb 2007 17:55:50 +1100 (EST) From: bnaujok@sgi.com (Barry Naujok) X-archive-position: 10694 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Content-Length: 767 Lines: 21 Copy modified superblock into mountpoint structure in phase 2 Date: Wed Feb 21 17:55:11 AEDT 2007 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: Nathan Scott [nscott@aconex.com] The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:28153a xfsprogs/repair/scan.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/scan.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - Copy modified superblock into mountpoint structure in phase 2 xfsprogs/libxfs/rdwr.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/rdwr.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h - Fix debug messages when IO_DEBUG is enabled From owner-xfs@oss.sgi.com Wed Feb 21 13:02:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 21 Feb 2007 13:03:00 -0800 (PST) X-Spam-oss-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1LL2rm7028458 for ; Wed, 21 Feb 2007 13:02:56 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 4D1E014B2B1; Wed, 21 Feb 2007 23:07:35 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GsyksNk77XkN; Wed, 21 Feb 2007 23:07:35 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 0585114B0E7; Wed, 21 Feb 2007 23:07:35 +0200 (IST) From: "Leon Kolchinsky" To: "'Timothy Shimmin'" , Subject: RE: xfsdump/xfsrestore question Date: Wed, 21 Feb 2007 23:02:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdVTOt80v+haiW6QAy4WJmQeduLRAArRwkw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <80FFF742E8A3FFB101CF1455@timothy-shimmins-power-mac-g5.local> Message-Id: <20070221210735.0585114B0E7@mail.edu.haifa.ac.il> X-archive-position: 10697 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 2430 Lines: 74 > > ># xfsdump -f /data/backup.file / > > > > Is it right? > > What about opened and "currently in use by the system" files? Are they > > backuped in a proper way? What about tmpfs like /proc, are they been > > ignored? > > > > Yes, the dump line looks reasonable (since /data is a different > filesystem). > As Justin mentioned the dump wants a couple of ids (session-id, media-id) > which > will be prompted for or you can specify then as command arguments. > >From the file xfsdump/doc/README.xfsdump: > 1. Dumping a filesystem to a dump file: > xfsdump -f dump_file -L session_label -M media_label file_system > e.g. xfsdump -f ./mydump -L 'session1' -M 'media1" /mnt/xfs0 > Yes it is meant to handle a changing filesystem - you do see warning msgs > sometimes because > it can't see a particular inode anymore, which can happen as we do > multiple > scans of the inodes and if they get deleted then it obviously can't do > anything > with it anymore or if the inode is reused as a dir instead of a reg-file > etc... > It won't dump out foreign filesystems mounted under / because it doesn't > actually do a directory walk to dump data but actually iterates through > all the inodes of the filesystem (using an xfs ioctl called bulkstat) (and > for a directory inode it will just dump out the dirents). > It won't dump out /var/lib/xfsdump which contains the dump inventory which > is > used for info for incremental dumps and resumed dumps. > > > 2) If I'd have to restore my system from the dump, how would you > recommend > > to do it? Booting from LiveCD and making # xfsrestore -f / > data/backup.file > > / ? > > > Booting from a filesystem other than the one your are restoring to - yes:) > > > Would it be a bootable/operational system? > Should be. > (Try it out:) > > --Tim > Thanks Justin,Timothy, It's clearing things out :) You right, man pages say that xfsdump can only dump XFS filesystems, so I don't worry about procfs now :) So,my backup command would look like this: xfsdump -L 'session1' -M 'media1" -f /data/sysbackup.file / But if I want to make an incremental backup now, should I use this command? xfsdump -l 1 -f /data/sysbackup.file / What incremental filename would be created in this case? Is the syntax right? Sorry, but man pages a little unclear for me on this issue and there is almost no examples showing xfsdump usage on the net :( Best Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Wed Feb 21 17:26:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 21 Feb 2007 17:26:43 -0800 (PST) X-Spam-oss-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1M1Qam7004340 for ; Wed, 21 Feb 2007 17:26:38 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA19208; Thu, 22 Feb 2007 12:26:35 +1100 Message-Id: <200702220126.MAA19208@larry.melbourne.sgi.com> From: "Barry Naujok" To: Cc: Subject: [PATCH] xfs_repair doesn't detect corrupt btree roots in nodes Date: Thu, 22 Feb 2007 12:32:43 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0190_01C7567D.8CBD37A0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdWIVkkHK4i+MFOTcyO7HrNHKhnvA== X-archive-position: 10698 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 6447 Lines: 202 This is a multi-part message in MIME format. ------=_NextPart_000_0190_01C7567D.8CBD37A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The attached patch detect invalid btree root field (numrecs = 0, levels > permissable value). The patch also does some cleanup with the level and numrecs usage for the process_btinode function. ------=_NextPart_000_0190_01C7567D.8CBD37A0 Content-Type: application/octet-stream; name="detect_bad_btree_root.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="detect_bad_btree_root.diff" --- a/xfsprogs/repair/dinode.c 2007-02-22 12:19:27.000000000 +1100 +++ b/xfsprogs/repair/dinode.c 2007-02-22 12:19:21.463097922 +1100 @@ -307,8 +307,8 @@ clear_dinode(xfs_mount_t *mp, xfs_dinode * misc. inode-related utility routines */ =20 -/*=20 - * verify_ag_bno is heavily used. In the common case, it=20 +/* + * verify_ag_bno is heavily used. In the common case, it * performs just two number of compares */ static __inline int @@ -802,7 +802,7 @@ process_bmbt_reclist_int( PROCESS_BMBT_UNLOCK_RETURN(1); } =20 - /* Process in chunks of 16 (XR_BB_UNIT/XR_BB)=20 + /* Process in chunks of 16 (XR_BB_UNIT/XR_BB) * for common XR_E_UNKNOWN to XR_E_INUSE transition */ if (((agbno & XR_BB_MASK) =3D=3D 0) && ((s + c - b) >=3D (XR_BB_UNIT/XR= _BB))) { @@ -1223,6 +1223,8 @@ process_btinode( xfs_bmbt_key_t *pkey; char *forkname; int i; + int level; + int numrecs; bmap_cursor_t cursor; =20 dib =3D (xfs_bmdr_block_t *)XFS_DFORK_PTR(dip, whichfork); @@ -1235,13 +1237,11 @@ process_btinode( else forkname =3D _("attr"); =20 - if (INT_GET(dib->bb_level, ARCH_CONVERT) =3D=3D 0) { + level =3D INT_GET(dib->bb_level, ARCH_CONVERT); + numrecs =3D INT_GET(dib->bb_numrecs, ARCH_CONVERT); + + if ((level =3D=3D 0) || (level > XFS_BM_MAXLEVELS(mp, whichfork))) { /* - * This should never happen since a btree inode - * has to have at least one other block in the - * bmap in addition to the root block in the - * inode's data fork. - * * XXX - if we were going to fix up the inode, * we'd try to treat the fork as an interior * node and see if we could get an accurate @@ -1249,28 +1249,30 @@ process_btinode( * to by the pointers in the fork. For now * though, we just bail (and blow out the inode). */ - do_warn(_("bad level 0 in inode %llu bmap btree root block\n"), + do_warn(_("bad level %d in inode %llu bmap btree root block\n"), + level, XFS_AGINO_TO_INO(mp, agno, ino)); + return(1); + } + if (numrecs =3D=3D 0) { + do_warn(_("bad numrecs 0 in inode %llu bmap btree root block\n"), XFS_AGINO_TO_INO(mp, agno, ino)); return(1); } /* * use bmdr/dfork_dsize since the root block is in the data fork */ - init_bm_cursor(&cursor, INT_GET(dib->bb_level, ARCH_CONVERT) + 1); - - if (XFS_BMDR_SPACE_CALC(INT_GET(dib->bb_numrecs, ARCH_CONVERT)) > - ((whichfork =3D=3D XFS_DATA_FORK) ? + if (XFS_BMDR_SPACE_CALC(numrecs) > ((whichfork =3D=3D XFS_DATA_FORK) ? XFS_DFORK_DSIZE(dip, mp) : XFS_DFORK_ASIZE(dip, mp))) { do_warn( _("indicated size of %s btree root (%d bytes) greater than space in " "inode %llu %s fork\n"), - forkname, XFS_BMDR_SPACE_CALC(INT_GET(dib->bb_numrecs, - ARCH_CONVERT)), - lino, forkname); + forkname, XFS_BMDR_SPACE_CALC(numrecs), lino, forkname); return(1); } =20 + init_bm_cursor(&cursor, level + 1); + pp =3D XFS_BTREE_PTR_ADDR( XFS_DFORK_SIZE(dip, mp, whichfork), xfs_bmdr, dib, 1, @@ -1286,7 +1288,7 @@ process_btinode( =20 last_key =3D NULLDFILOFF; =20 - for (i =3D 0; i < INT_GET(dib->bb_numrecs, ARCH_CONVERT); i++) { + for (i =3D 0; i < numrecs; i++) { /* * XXX - if we were going to do more to fix up the inode * btree, we'd do it right here. For now, if there's a @@ -1298,8 +1300,8 @@ process_btinode( return(1); } =20 - if (scan_lbtree((xfs_dfsbno_t)INT_GET(pp[i], ARCH_CONVERT), INT_GET(dib-= >bb_level, ARCH_CONVERT), - scanfunc_bmap, type, whichfork, + if (scan_lbtree((xfs_dfsbno_t)INT_GET(pp[i], ARCH_CONVERT), + level, scanfunc_bmap, type, whichfork, lino, tot, nex, blkmapp, &cursor, 1, check_dups)) return(1); @@ -1310,8 +1312,7 @@ process_btinode( * blocks but the parent hasn't been updated */ if (check_dups =3D=3D 0 && - cursor.level[INT_GET(dib->bb_level, - ARCH_CONVERT)-1].first_key !=3D + cursor.level[level-1].first_key !=3D INT_GET(pkey[i].br_startoff, ARCH_CONVERT)) { if (!no_modify) { do_warn( @@ -1319,22 +1320,19 @@ process_btinode( "%llu %s fork\n"), INT_GET(pkey[i].br_startoff, ARCH_CONVERT), - cursor.level[INT_GET(dib->bb_level, - ARCH_CONVERT)-1].first_key, + cursor.level[level-1].first_key, XFS_AGINO_TO_INO(mp, agno, ino), forkname); *dirty =3D 1; INT_SET(pkey[i].br_startoff, ARCH_CONVERT, - cursor.level[INT_GET(dib->bb_level, - ARCH_CONVERT)-1].first_key); + cursor.level[level-1].first_key); } else { do_warn( _("bad key in bmbt root (is %llu, would reset to %llu) in inode " "%llu %s fork\n"), INT_GET(pkey[i].br_startoff, ARCH_CONVERT), - cursor.level[INT_GET(dib->bb_level, - ARCH_CONVERT)-1].first_key, + cursor.level[level-1].first_key, XFS_AGINO_TO_INO(mp, agno, ino), forkname); } @@ -1345,8 +1343,7 @@ process_btinode( */ if (check_dups =3D=3D 0) { if (last_key !=3D NULLDFILOFF && last_key >=3D - cursor.level[INT_GET(dib->bb_level, - ARCH_CONVERT)-1].first_key) { + cursor.level[level-1].first_key) { do_warn( _("out of order bmbt root key %llu in inode %llu %s fork\n"), first_key, @@ -1354,8 +1351,7 @@ process_btinode( forkname); return(1); } - last_key =3D cursor.level[INT_GET(dib->bb_level, - ARCH_CONVERT)-1].first_key; + last_key =3D cursor.level[level-1].first_key; } } /* @@ -2064,9 +2060,9 @@ process_dinode_int(xfs_mount_t *mp, if (!verify_mode) { do_warn(_("bad inode type %#o inode %llu\n"), (int) (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT), lino); - if (!no_modify)=20=20 + if (!no_modify) *dirty +=3D clear_dinode(mp, dino, lino); - else=20 + else *dirty =3D 1; *cleared =3D 1; *used =3D is_free; ------=_NextPart_000_0190_01C7567D.8CBD37A0-- From owner-xfs@oss.sgi.com Thu Feb 22 05:02:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Feb 2007 05:02:18 -0800 (PST) X-Spam-oss-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_20, FH_HOST_EQ_D_D_D_D,MIME_8BIT_HEADER,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r497472 Received: from zeus.office.navi.pl (ip-83-238-212-180.netia.com.pl [83.238.212.180]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1MD2Bm7026734 for ; Thu, 22 Feb 2007 05:02:12 -0800 Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by zeus.office.navi.pl (8.13.1/8.13.1) with ESMTP id l1MCmHFe005802; Thu, 22 Feb 2007 13:48:18 +0100 Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.13.1/8.13.1) with ESMTP id l1MCmHsR008091; Thu, 22 Feb 2007 13:48:17 +0100 Subject: Re: xfsdump/xfsrestore question From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Timothy Shimmin Cc: Leon Kolchinsky , xfs@oss.sgi.com In-Reply-To: <80FFF742E8A3FFB101CF1455@timothy-shimmins-power-mac-g5.local> References: <20070220142114.2B52C1C9C6@mail.edu.haifa.ac.il> <80FFF742E8A3FFB101CF1455@timothy-shimmins-power-mac-g5.local> Content-Type: text/plain; charset=UTF-8 Date: Thu, 22 Feb 2007 13:48:17 +0100 Message-Id: <1172148497.4634.36.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 8bit X-archive-position: 10701 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: xfs Content-Length: 1351 Lines: 45 On Wed, 2007-02-21 at 11:07 +1100, Timothy Shimmin wrote: > Hi, > > --On 20 February 2007 4:16:31 PM +0200 Leon Kolchinsky wrote: > > > Hello All, > > > > I have a question about xfsdump/xfsrestore usage on Linux. > > > > Now the questions: > > > > 1) If I get the xfsdump synax correctly I just have to do: > > > ># cd / > ># xfsdump -f /data/backup.file / > > > > Is it right? > > What about opened and "currently in use by the system" files? Are they > > backuped in a proper way? What about tmpfs like /proc, are they been > > ignored? > > (...) > Yes it is meant to handle a changing filesystem - you do see warning msgs sometimes because > it can't see a particular inode anymore, which can happen as we do multiple > scans of the inodes and if they get deleted then it obviously can't do anything > with it anymore or if the inode is reused as a dir instead of a reg-file etc... Hmm, I suppose he asked about something else: Unless you use lvm snapshots (or something alike) you may get incorrect files that are in use. Consider having 20GB file: 1. Dump starts reading the file 2. Dump is at 18th GB 3. You change the data in 1-5 GB region. 4. You have inconsistent data. So after dump you get consistent filesystem but not necessairly consistent data. Regards, Olaf -- Olaf FrÄ…czyk From owner-xfs@oss.sgi.com Thu Feb 22 20:50:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Feb 2007 20:50:16 -0800 (PST) X-Spam-oss-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r497472 Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1N4o8m7015649 for ; Thu, 22 Feb 2007 20:50:09 -0800 Received: from tyo202.gate.nec.co.jp ([10.7.69.202]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l1N4S1qD009451 for ; Fri, 23 Feb 2007 13:28:04 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l1N4MdcU004301 for ; Fri, 23 Feb 2007 13:22:39 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l1N4Md110319 for xfs@oss.sgi.com; Fri, 23 Feb 2007 13:22:39 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id l1N4Mc229500 for ; Fri, 23 Feb 2007 13:22:38 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20070223.132238.46902096 for ; Fri, 23 Feb 2007 13:22:38 +0900 Received: FROM tnessv1.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Fri Feb 23 13:22:38 2007 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by tnessv1.tnes.nec.co.jp (Postfix) with ESMTP id 8E7E1AE4B0 for ; Fri, 23 Feb 2007 13:22:33 +0900 (JST) Received: from TNESG9700 (TNESG9700.bsd.tnes.nec.co.jp [10.1.104.115]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with SMTP id l1N4MbrZ021664 for ; Fri, 23 Feb 2007 13:22:37 +0900 To: xfs@oss.sgi.com Subject: [PATCH 1/2] Fix failure of switch on group quota enforcement Message-Id: <20070223132239k-ooizumi@rifu.bsd.tnes.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Kouta Ooizumi Date: Fri, 23 Feb 2007 13:22:39 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 10704 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: k-ooizumi@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 1946 Lines: 54 Hi! I found that "quotaon -g /mnt" fails to switch on group quota enforcement. Example: # mount -t xfs -o gqnoenforce /dev/sda6 /mnt/xfs # quotaon -g /mnt/xfs Enabling group quota accounting on /dev/sda6 quotaon: quotactl on /dev/sda6: Invalid argument The problem is the following: fs/xfs/quota/xfs_qm_syscalls.c 455L if (((flags & XFS_UQUOTA_ACCT) == 0 && (mp->m_sb.sb_qflags & XFS_UQUOTA_ACCT) == 0 && (flags & XFS_UQUOTA_ENFD)) || ((flags & XFS_PQUOTA_ACCT) == 0 && ** (mp->m_sb.sb_qflags & XFS_PQUOTA_ACCT) == 0 && ** (flags & XFS_OQUOTA_ENFD)) ** || ** ((flags & XFS_GQUOTA_ACCT) == 0 && ** (mp->m_sb.sb_qflags & XFS_GQUOTA_ACCT) == 0 && ** (flags & XFS_OQUOTA_ENFD))) { ** qdprintk("Can't enforce without acct, flags=%x sbflags=%x\n", flags, mp->m_sb.sb_qflags); return XFS_ERROR(EINVAL); } XFS_PQUOTA_ACCT and XFS_GQUOTA_ACCT cannot be enabled at the same time. But this if-statement is not considered it. Here is the patch. Signed-off-by: Kouta Ooizumi --- linux-2.6.20/fs/xfs/quota/xfs_qm_syscalls.c.orig 2007-02-20 15:41:58.000000000 +0900 +++ linux-2.6.20/fs/xfs/quota/xfs_qm_syscalls.c 2007-02-20 15:43:49.000000000 +0900 @@ -458,9 +458,7 @@ xfs_qm_scall_quotaon( || ((flags & XFS_PQUOTA_ACCT) == 0 && (mp->m_sb.sb_qflags & XFS_PQUOTA_ACCT) == 0 && - (flags & XFS_OQUOTA_ENFD)) - || - ((flags & XFS_GQUOTA_ACCT) == 0 && + (flags & XFS_GQUOTA_ACCT) == 0 && (mp->m_sb.sb_qflags & XFS_GQUOTA_ACCT) == 0 && (flags & XFS_OQUOTA_ENFD))) { qdprintk("Can't enforce without acct, flags=%x sbflags=%x\n", From owner-xfs@oss.sgi.com Thu Feb 22 21:14:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Feb 2007 21:14:41 -0800 (PST) X-Spam-oss-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.0-pre1-r497472 Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1N5ETm7019123 for ; Thu, 22 Feb 2007 21:14:31 -0800 Received: from tyo202.gate.nec.co.jp ([10.7.69.202]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l1N4S1vR009451 for ; Fri, 23 Feb 2007 13:28:22 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l1N4NHTb005260 for ; Fri, 23 Feb 2007 13:23:17 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l1N4NHP15173 for xfs@oss.sgi.com; Fri, 23 Feb 2007 13:23:17 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id l1N4NH200133 for ; Fri, 23 Feb 2007 13:23:17 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20070223.132317.29702160 for ; Fri, 23 Feb 2007 13:23:17 +0900 Received: FROM tnessv1.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Fri Feb 23 13:23:16 2007 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by tnessv1.tnes.nec.co.jp (Postfix) with ESMTP id 1E2AEAE4B0 for ; Fri, 23 Feb 2007 13:23:12 +0900 (JST) Received: from TNESG9700 (TNESG9700.bsd.tnes.nec.co.jp [10.1.104.115]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with SMTP id l1N4NGE5021754 for ; Fri, 23 Feb 2007 13:23:16 +0900 To: xfs@oss.sgi.com Subject: [PATCH 2/2] Fix a bug which is in user or group quota enforcement disabled Message-Id: <20070223132318k-ooizumi@rifu.bsd.tnes.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Kouta Ooizumi Date: Fri, 23 Feb 2007 13:23:18 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 10705 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: k-ooizumi@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 6035 Lines: 145 Hi! I found a bug in the following conditions. Conditions: - Both XFS_UQUOTA_ACCT and XFS_GQUOTA_ACCT are enabled. - Either XFS_UQUOTA_ENFD or XFS_OQUOTA_ENFD is enabled. - The usage without enforce is reached at the soft limit. Problems: 1. "repquota" shows all grace time even if no enforcement. 2. we cannot make a file over a hard limits even if no enforcement. Factor: - Following if-statements are considered "disabled all enforcement" only. 1. xfs_qm_export_dquot() in fs/xfs/quota/xfs_qm_syscalls.c if (! XFS_IS_QUOTA_ENFORCED(mp)) { ** dst->d_btimer = 0; dst->d_itimer = 0; dst->d_rtbtimer = 0; } 2. xfs_trans_dqresv() in fs/xfs/quota/xfs_trans_dquot.c if ((flags & XFS_QMOPT_FORCE_RES) == 0 && dqp->q_core.d_id && XFS_IS_QUOTA_ENFORCED(dqp->q_mount)) { ** Example: # mount -t xfs -o usrquota,grpquota /dev/sda6 /mnt/xfs # repquota -ug /mnt *** Report for user quotas on device /dev/sda6 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 0 0 0 2 0 0 k-ooizumi +- 1024 1000 2000 3days 2 0 0 xfstest -- 2048 0 0 2 0 0 *** Report for group quotas on device /dev/sda6 Block grace time: 7days; Inode grace time: 7days Block limits File limits Group used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 0 0 0 2 0 0 users +- 3072 3000 4000 6days 4 0 0 # quotaoff -g(or -u) -x enforce /mnt/xfs # repquota -vug /mnt/xfs *** Report for user quotas on device /dev/sda6 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 0 0 0 2 0 0 k-ooizumi +- 1024 1000 2000 3days 2 0 0 xfstest -- 2048 0 0 2 0 0 *** Status for user quotas on device /dev/sda6 Accounting: ON; Enforcement: ON Inode: #131 (2 blocks, 2 extents) *** Report for group quotas on device /dev/sda6 Block grace time: 7days; Inode grace time: 7days Block limits File limits Group used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 0 0 0 2 0 0 users +- 3072 3000 4000 6days 4 0 0 *** Status for group quotas on device /dev/sda6 Accounting: ON; Enforcement: OFF Inode: #132 (2 blocks, 2 extents) xfstest@*** > /usr/sbin/xfs_mkfile 1m /mnt/xfs/file_1 /mnt/xfs/file_1: Disk quota exceeded Here is the patch. Signed-off-by: Kouta Ooizumi diff -uprN linux-2.6.20-orig/fs/xfs/quota/xfs_qm_syscalls.c linux-2.6.20/fs/xfs/quota/xfs_qm_syscalls.c --- linux-2.6.20-orig/fs/xfs/quota/xfs_qm_syscalls.c 2007-02-22 20:14:16.000000000 +0900 +++ linux-2.6.20/fs/xfs/quota/xfs_qm_syscalls.c 2007-02-23 11:06:26.000000000 +0900 @@ -911,14 +911,19 @@ xfs_qm_export_dquot( * gets turned off. No need to confuse the user level code, * so return zeroes in that case. */ - if (! XFS_IS_QUOTA_ENFORCED(mp)) { + if ((!XFS_IS_UQUOTA_ENFORCED(mp) && src->d_flags == XFS_DQ_USER) || + (!XFS_IS_OQUOTA_ENFORCED(mp) && + (src->d_flags & (XFS_DQ_PROJ | XFS_DQ_GROUP)))) { dst->d_btimer = 0; dst->d_itimer = 0; dst->d_rtbtimer = 0; } #ifdef DEBUG - if (XFS_IS_QUOTA_ENFORCED(mp) && dst->d_id != 0) { + if (((XFS_IS_UQUOTA_ENFORCED(mp) && dst->d_flags == XFS_USER_QUOTA) || + (XFS_IS_OQUOTA_ENFORCED(mp) && + (dst->d_flags & (XFS_PROJ_QUOTA | XFS_GROUP_QUOTA)))) && + dst->d_id != 0) { if (((int) dst->d_bcount >= (int) dst->d_blk_softlimit) && (dst->d_blk_softlimit > 0)) { ASSERT(dst->d_btimer != 0); diff -uprN linux-2.6.20-orig/fs/xfs/quota/xfs_trans_dquot.c linux-2.6.20/fs/xfs/quota/xfs_trans_dquot.c --- linux-2.6.20-orig/fs/xfs/quota/xfs_trans_dquot.c 2007-02-05 03:44:54.000000000 +0900 +++ linux-2.6.20/fs/xfs/quota/xfs_trans_dquot.c 2007-02-23 11:06:23.000000000 +0900 @@ -658,7 +658,9 @@ xfs_trans_dqresv( if ((flags & XFS_QMOPT_FORCE_RES) == 0 && dqp->q_core.d_id && - XFS_IS_QUOTA_ENFORCED(dqp->q_mount)) { + ((XFS_IS_UQUOTA_ENFORCED(dqp->q_mount) && XFS_QM_ISUDQ(dqp)) || + (XFS_IS_OQUOTA_ENFORCED(dqp->q_mount) && + (XFS_QM_ISPDQ(dqp) || XFS_QM_ISGDQ(dqp))))) { #ifdef QUOTADEBUG cmn_err(CE_DEBUG, "BLK Res: nblks=%ld + resbcount=%Ld" " > hardlimit=%Ld?", nblks, *resbcountp, hardlimit); diff -uprN linux-2.6.20-orig/fs/xfs/xfs_quota.h linux-2.6.20/fs/xfs/xfs_quota.h --- linux-2.6.20-orig/fs/xfs/xfs_quota.h 2007-02-05 03:44:54.000000000 +0900 +++ linux-2.6.20/fs/xfs/xfs_quota.h 2007-02-23 11:06:19.000000000 +0900 @@ -154,10 +154,11 @@ typedef struct xfs_qoff_logformat { #define XFS_ALL_QUOTA_CHKD (XFS_UQUOTA_CHKD | XFS_OQUOTA_CHKD) #define XFS_IS_QUOTA_RUNNING(mp) ((mp)->m_qflags & XFS_ALL_QUOTA_ACCT) -#define XFS_IS_QUOTA_ENFORCED(mp) ((mp)->m_qflags & XFS_ALL_QUOTA_ENFD) #define XFS_IS_UQUOTA_RUNNING(mp) ((mp)->m_qflags & XFS_UQUOTA_ACCT) #define XFS_IS_PQUOTA_RUNNING(mp) ((mp)->m_qflags & XFS_PQUOTA_ACCT) #define XFS_IS_GQUOTA_RUNNING(mp) ((mp)->m_qflags & XFS_GQUOTA_ACCT) +#define XFS_IS_UQUOTA_ENFORCED(mp) ((mp)->m_qflags & XFS_UQUOTA_ENFD) +#define XFS_IS_OQUOTA_ENFORCED(mp) ((mp)->m_qflags & XFS_OQUOTA_ENFD) /* * Incore only flags for quotaoff - these bits get cleared when quota(s) From owner-xfs@oss.sgi.com Fri Feb 23 11:13:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Feb 2007 11:13:08 -0800 (PST) X-Spam-oss-Status: No, score=3.0 required=5.0 tests=AWL,BAYES_80,SPF_HELO_PASS, WHOIS_MYPRIVREG autolearn=no version=3.2.0-pre1-r497472 Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1NJD3m7028568 for ; Fri, 23 Feb 2007 11:13:04 -0800 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HKfqp-0003BW-CY for linux-xfs@oss.sgi.com; Fri, 23 Feb 2007 11:13:03 -0800 Message-ID: <9124908.post@talk.nabble.com> Date: Fri, 23 Feb 2007 11:13:03 -0800 (PST) From: pgf111000 To: linux-xfs@oss.sgi.com Subject: I/O error, SCSI error, reservation conflict.... xfs suggestions? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: junkmail@petergfrazier.com X-archive-position: 10708 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: junkmail@petergfrazier.com Precedence: bulk X-list: xfs Content-Length: 1700 Lines: 44 Hello all- I am in an fc6 x86_64 environment on an lvm2 ext3 fs (mkfs'd to a segate 750)... this is the host os. The target os is a CLFS environment, which is built on a areca 1280 hw raid6 (arcmsr driver compiled from source) 4 seagates (750s) array; all of the above on an AMD Opteron based tyan board..... the target os has three primary partitions: boot- xfs swap- swap lvm2 The lvm partition has one pv (being the areca array); the lvm has multiple lv's.... a few lv's are straight xfs, other lv's are LUKS w/ the mapped drive being xfs. I'v read the doc at: http://web.bii.a-star.edu.sg/~james/100TB/14TB/#f ...it's useful, but... In the middle of read/write operations on the xfs formatted areca array I experience the following repetative message (from /var/log/messages): sd 3:0:1:0: reservation conflict sd 3:0:1:0: SCSI error: return code = 0x00070018 end_request: I/O error, dev sdx, sector 681896097 The "SCSI error: return code" consistently returns "0x00070018". The "end_request: I/O error, dev sdx, sector" returns various sector values. The opteron produces significant io wait during these errors; the read/write performance is marginal (in general). I have run xfs_check on all the parititions (LUKS/xfs and xfs)... no errors. I have scanned the array volume (on the hardware level)... no errors. I have run badblocks -nsv ...on most of the parititions (LUKS/xfs and xfs)... no error. Any and all thoughts/suggestions will be warmly received.... -- View this message in context: http://www.nabble.com/I-O-error%2C-SCSI-error%2C-reservation-conflict....-xfs-suggestions--tf3280660.html#a9124908 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Fri Feb 23 11:35:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Feb 2007 11:35:26 -0800 (PST) X-Spam-oss-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1NJZHm7032093 for ; Fri, 23 Feb 2007 11:35:19 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1NJZHaI009280; Fri, 23 Feb 2007 14:35:17 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1NJZB9m012490; Fri, 23 Feb 2007 14:35:11 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1NJZA4Z006057; Fri, 23 Feb 2007 14:35:11 -0500 Message-ID: <45DF416F.5050907@sandeen.net> Date: Fri, 23 Feb 2007 13:33:03 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: pgf111000 CC: linux-xfs@oss.sgi.com Subject: Re: I/O error, SCSI error, reservation conflict.... xfs suggestions? References: <9124908.post@talk.nabble.com> In-Reply-To: <9124908.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10710 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 554 Lines: 19 pgf111000 wrote: > In the middle of read/write operations on the xfs formatted areca array I > experience the following repetative message (from /var/log/messages): > > sd 3:0:1:0: reservation conflict > sd 3:0:1:0: SCSI error: return code = 0x00070018 > end_request: I/O error, dev sdx, sector 681896097 ... > Any and all thoughts/suggestions will be warmly received.... Well, this isn't an xfs problem. Something is happening at the scsi layer, whatever xfs does after that is simply reacting (properly) to it. I'd try another list... :) -Eric From owner-xfs@oss.sgi.com Fri Feb 23 12:08:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Feb 2007 12:08:38 -0800 (PST) X-Spam-oss-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_20 autolearn=ham version=3.2.0-pre1-r497472 Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1NK8Wm7004587 for ; Fri, 23 Feb 2007 12:08:33 -0800 Received: (qmail 78611 invoked from network); 23 Feb 2007 19:41:52 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 23 Feb 2007 19:41:52 -0000 X-YMail-OSG: uPNUbDwVM1mG_BRa9Vbj4bYUChXx.ISU6WIO3vj_YXaDQyw8f27eqP51t10vcc2WWKg0HM0gEWsMKia6894TBzADjd5y6XVWhtbKVzik1pI4OPfOPTSqS0watxDiTFEaZxRm5ATVG2Zc9A-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 754521826125; Fri, 23 Feb 2007 11:41:50 -0800 (PST) Date: Fri, 23 Feb 2007 11:41:50 -0800 From: Chris Wedgwood To: pgf111000 Cc: linux-xfs@oss.sgi.com Subject: Re: I/O error, SCSI error, reservation conflict.... xfs suggestions? Message-ID: <20070223194150.GA31001@tuatara.stupidest.org> References: <9124908.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9124908.post@talk.nabble.com> X-archive-position: 10713 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 323 Lines: 12 On Fri, Feb 23, 2007 at 11:13:03AM -0800, pgf111000 wrote: > sd 3:0:1:0: reservation conflict some other host has reserve (part) of your storage system, best you go whack them or something > sd 3:0:1:0: SCSI error: return code = 0x00070018 > end_request: I/O error, dev sdx, sector 681896097 low-level errors, not XFS From owner-xfs@oss.sgi.com Sat Feb 24 07:04:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 24 Feb 2007 07:04:58 -0800 (PST) X-Spam-oss-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_12,J_CHICKENPOX_24 autolearn=no version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1OF4km7020155 for ; Sat, 24 Feb 2007 07:04:48 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 1DE9214AB49; Sat, 24 Feb 2007 17:09:34 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fe0NyFGE2paQ; Sat, 24 Feb 2007 17:09:33 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id BFE26200D8; Sat, 24 Feb 2007 17:09:33 +0200 (IST) From: "Leon Kolchinsky" To: "'Olaf Fr?czyk'" , "'Timothy Shimmin'" Cc: Subject: RE: xfsdump/xfsrestore question Date: Sat, 24 Feb 2007 17:04:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdWgG5RGY26XwQfQdu21Oukjw/SVABo6bdQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <1172148497.4634.36.camel@venus.local.navi.pl> Message-Id: <20070224150933.BFE26200D8@mail.edu.haifa.ac.il> X-archive-position: 10714 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 2998 Lines: 103 > (...) > > Yes it is meant to handle a changing filesystem - you do see warning > msgs sometimes because > > it can't see a particular inode anymore, which can happen as we do > multiple > > scans of the inodes and if they get deleted then it obviously can't do > anything > > with it anymore or if the inode is reused as a dir instead of a reg-file > etc... > Hmm, > I suppose he asked about something else: > Unless you use lvm snapshots (or something alike) you may get incorrect > files that are in use. Consider having 20GB file: > 1. Dump starts reading the file > 2. Dump is at 18th GB > 3. You change the data in 1-5 GB region. > 4. You have inconsistent data. > > So after dump you get consistent filesystem but not necessairly > consistent data. > Yep, consistent FS is what I care about in the case of disaster. Now, when I've tried to make non-interactive xfsdump I'vo got > prompt with no action, like this # xfsdump -f /data/backup2.file -L 'session1' -M 'media1" / > # So, I've got to Ctrl+C the process. Questions: 1) What could be the syntax problem in the above command? 2) Any examples for incremental xfsdump (non-interactive, i.e. run from cronjob) would be very welcome (and also comments about xfsrestore from these backups). On the other hand, interactive xfsdump went fine: # xfsdump -f /data/sysbackup.file / xfsdump: using file dump (drive_simple) strategy xfsdump: version 2.2.42 (dump format 3.0) - Running single-threaded ============================= dump label dialog ============================== please enter label for this dump session (timeout in 300 sec) -> label1 session label entered: "label1" --------------------------------- end dialog --------------------------------- xfsdump: level 0 dump of vod:/ xfsdump: dump date: Fri Feb 23 16:38:05 2007 xfsdump: session id: 53a70b7b-5114-41ae-9a82-6b2f3d0e394c xfsdump: session label: "label1" xfsdump: ino map phase 1: constructing initial dump list xfsdump: ino map phase 2: skipping (no pruning necessary) xfsdump: ino map phase 3: skipping (only one dump stream) xfsdump: ino map construction complete xfsdump: estimated dump size: 2053243392 bytes xfsdump: /var/lib/xfsdump/inventory created ============================= media label dialog ============================= please enter label for media in drive 0 (timeout in 300 sec) -> media1 media label entered: "media1" --------------------------------- end dialog --------------------------------- xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map xfsdump: dumping directories xfsdump: dumping non-directory files xfsdump: ending media file xfsdump: media file size 1503663968 bytes xfsdump: dump size (non-dir files) : 1425357712 bytes xfsdump: dump complete: 577 seconds elapsed xfsdump: Dump Status: SUCCESS vod / # ls -lh /data total 1.5G -rw-r--r-- 1 root root 1.5G Feb 23 16:47 sysbackup.file # # > Regards, > > Olaf > > -- > Olaf Fr?czyk Best Regards, Leon From owner-xfs@oss.sgi.com Sat Feb 24 07:10:44 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 24 Feb 2007 07:10:51 -0800 (PST) X-Spam-oss-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_05, J_CHICKENPOX_12,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r497472 Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1OFAcm7021581 for ; Sat, 24 Feb 2007 07:10:43 -0800 Received: from teal.hq.k1024.org (84-75-131-239.dclient.hispeed.ch [84.75.131.239]) by astra.simleu.ro (Postfix) with ESMTP id 726AC16F; Sat, 24 Feb 2007 17:10:36 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id C0CDE40A0CB; Sat, 24 Feb 2007 16:10:26 +0100 (CET) Date: Sat, 24 Feb 2007 16:10:26 +0100 From: Iustin Pop To: Leon Kolchinsky Cc: "'Olaf Fr?czyk'" , "'Timothy Shimmin'" , xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore question Message-ID: <20070224151026.GA16887@teal.hq.k1024.org> Mail-Followup-To: Leon Kolchinsky , 'Olaf Fr?czyk' , 'Timothy Shimmin' , xfs@oss.sgi.com References: <1172148497.4634.36.camel@venus.local.navi.pl> <20070224150933.BFE26200D8@mail.edu.haifa.ac.il> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070224150933.BFE26200D8@mail.edu.haifa.ac.il> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 10715 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Content-Length: 764 Lines: 25 On Sat, Feb 24, 2007 at 05:04:33PM +0200, Leon Kolchinsky wrote: > Now, when I've tried to make non-interactive xfsdump I'vo got > prompt with > no action, like this > # xfsdump -f /data/backup2.file -L 'session1' -M 'media1" / > > > # > > So, I've got to Ctrl+C the process. > > Questions: > 1) What could be the syntax problem in the above command? > 2) Any examples for incremental xfsdump (non-interactive, i.e. run from > cronjob) would be very welcome (and also comments about xfsrestore from > these backups). My non-interactive backup is (fragment from a script): xfsdump -e -l $level -L "dump $lv at $day" - /$lv | gzip -v9 > $dest_file and it works without prompts. Combining this with LVM snapshots also makes consistent backups. Regards, Iustin From owner-xfs@oss.sgi.com Sun Feb 25 21:30:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Feb 2007 21:30:23 -0800 (PST) X-Spam-oss-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_12 autolearn=no version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1Q5UDm7014975 for ; Sun, 25 Feb 2007 21:30:15 -0800 Received: from [134.14.55.84] (shark.melbourne.sgi.com [134.14.55.84]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA27270; Mon, 26 Feb 2007 16:29:59 +1100 Message-ID: <45E27050.6080609@sgi.com> Date: Mon, 26 Feb 2007 16:29:52 +1100 From: Donald Douwsma User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Leon Kolchinsky CC: "'Olaf Fr?czyk'" , "'Timothy Shimmin'" , xfs@oss.sgi.com Subject: Re: xfsdump/xfsrestore question References: <20070224150933.BFE26200D8@mail.edu.haifa.ac.il> In-Reply-To: <20070224150933.BFE26200D8@mail.edu.haifa.ac.il> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 7bit X-archive-position: 10720 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Content-Length: 808 Lines: 29 Leon Kolchinsky wrote: > Now, when I've tried to make non-interactive xfsdump I'vo got > prompt with > no action, like this > # xfsdump -f /data/backup2.file -L 'session1' -M 'media1" / > # > > So, I've got to Ctrl+C the process. > > Questions: > 1) What could be the syntax problem in the above command? The above command seems to have a typo wrt unbalanced quotes. I'd say the " at the end of line is making the shell hang around waiting for you to match the quotes (' and "). So xfsdump is not actually running. Try xfsdump -f /data/backup2.file -L 'session1' -M 'media1' / > 2) Any examples for incremental xfsdump (non-interactive, i.e. run from > cronjob) would be very welcome (and also comments about xfsrestore from > these backups). > > On the other hand, interactive xfsdump went fine: From owner-xfs@oss.sgi.com Sun Feb 25 21:51:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Feb 2007 21:51:56 -0800 (PST) X-Spam-oss-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_12 autolearn=no version=3.2.0-pre1-r497472 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1Q5pmm7018981 for ; Sun, 25 Feb 2007 21:51:50 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA28216; Mon, 26 Feb 2007 16:51:40 +1100 Date: Mon, 26 Feb 2007 16:52:47 +1100 From: Timothy Shimmin To: Leon Kolchinsky , "'Olaf Fr?czyk'" cc: xfs@oss.sgi.com Subject: RE: xfsdump/xfsrestore question Message-ID: <3D67095B5C9E951BA3DB9BD5@timothy-shimmins-power-mac-g5.local> In-Reply-To: <20070224150933.BFE26200D8@mail.edu.haifa.ac.il> References: <20070224150933.BFE26200D8@mail.edu.haifa.ac.il> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 10721 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 1739 Lines: 47 --On 24 February 2007 5:04:33 PM +0200 Leon Kolchinsky wrote: >> (...) >> > Yes it is meant to handle a changing filesystem - you do see warning >> msgs sometimes because >> > it can't see a particular inode anymore, which can happen as we do >> multiple >> > scans of the inodes and if they get deleted then it obviously can't do >> anything >> > with it anymore or if the inode is reused as a dir instead of a reg-file >> etc... >> Hmm, >> I suppose he asked about something else: >> Unless you use lvm snapshots (or something alike) you may get incorrect >> files that are in use. Consider having 20GB file: >> 1. Dump starts reading the file >> 2. Dump is at 18th GB >> 3. You change the data in 1-5 GB region. >> 4. You have inconsistent data. >> >> So after dump you get consistent filesystem but not necessairly >> consistent data. >> > > Yep, consistent FS is what I care about in the case of disaster. > I'm not sure I know exactly what you are getting at. After the restore you should have a consistent FS because it is _not_ a low level filesystem dumper. It is mostly a high lever dump/restore program and to the extent that it can generally restore to a foreign filesystem e.g. ext2. (For example, it does know about file extents but it only uses this info on restore to preserve holes by seeking and writing.) So as it is just doing standard system calls on restore, it can't really violate filesystem consistency. > Now, when I've tried to make non-interactive xfsdump I'vo got > prompt with > no action, like this ># xfsdump -f /data/backup2.file -L 'session1' -M 'media1" / >> Presumably quoting problem as Donald pointed out - it definitely works otherwise without extra input. --Tim From owner-xfs@oss.sgi.com Mon Feb 26 05:16:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 26 Feb 2007 05:16:55 -0800 (PST) X-Spam-oss-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_12 autolearn=no version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1QDGom7005075 for ; Mon, 26 Feb 2007 05:16:52 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 4BE0214B15C; Mon, 26 Feb 2007 15:21:45 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 99a3VR7mz0uy; Mon, 26 Feb 2007 15:21:45 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 12C281FF44; Mon, 26 Feb 2007 15:21:45 +0200 (IST) From: "Leon Kolchinsky" To: "'Timothy Shimmin'" , "'Olaf Fr?czyk'" Cc: Subject: RE: xfsdump/xfsrestore question Date: Mon, 26 Feb 2007 15:16:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdZaugsxTAjpRnnTn6eBGsXu6ZumAAPT5oQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <3D67095B5C9E951BA3DB9BD5@timothy-shimmins-power-mac-g5.local> Message-Id: <20070226132145.12C281FF44@mail.edu.haifa.ac.il> X-archive-position: 10723 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 1014 Lines: 35 > > Yep, consistent FS is what I care about in the case of disaster. > > > I'm not sure I know exactly what you are getting at. > After the restore you should have a consistent FS because it is _not_ > a low level filesystem dumper. It is mostly a high lever dump/restore > program and to the extent that it can generally restore to a foreign > filesystem e.g. ext2. > (For example, it does know about file extents but it only uses this info > on restore to > preserve holes by seeking and writing.) > So as it is just doing standard system calls on restore, it can't really > violate filesystem consistency. > > > > Now, when I've tried to make non-interactive xfsdump I'vo got > prompt > with > > no action, like this > ># xfsdump -f /data/backup2.file -L 'session1' -M 'media1" / > >> > Presumably quoting problem as Donald pointed out - it definitely works > otherwise > without extra input. > Thanks Donald, Timothy It was indeed quotes problem :) It's running OK now. Best Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Mon Feb 26 05:14:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 26 Feb 2007 05:14:48 -0800 (PST) X-Spam-oss-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50, J_CHICKENPOX_12 autolearn=no version=3.2.0-pre1-r497472 Received: from mail.edu.haifa.ac.il (mail.edu.haifa.ac.il [132.74.40.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1QDEbm7004509 for ; Mon, 26 Feb 2007 05:14:40 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 7CCCF201D2; Mon, 26 Feb 2007 15:19:30 +0200 (IST) Received: from mail.edu.haifa.ac.il ([127.0.0.1]) by localhost (mail.edu.haifa.ac.il [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7eJ5DGTTYYRL; Mon, 26 Feb 2007 15:19:30 +0200 (IST) Received: from kozanostra (leon.edu.haifa.ac.il [132.74.41.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.edu.haifa.ac.il (Postfix) with ESMTP id 477521FDCF; Mon, 26 Feb 2007 15:19:30 +0200 (IST) From: "Leon Kolchinsky" To: "'Iustin Pop'" Cc: "'Olaf Fr?czyk'" , "'Timothy Shimmin'" , Subject: RE: xfsdump/xfsrestore question Date: Mon, 26 Feb 2007 15:14:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdYJqomKUmgSxFqT36uI4B9WABjKABaxotQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070224151026.GA16887@teal.hq.k1024.org> Message-Id: <20070226131930.477521FDCF@mail.edu.haifa.ac.il> X-archive-position: 10722 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: leonk@construct.haifa.ac.il Precedence: bulk X-list: xfs Content-Length: 2264 Lines: 70 > On Sat, Feb 24, 2007 at 05:04:33PM +0200, Leon Kolchinsky wrote: > > Now, when I've tried to make non-interactive xfsdump I'vo got > prompt > with > > no action, like this > > # xfsdump -f /data/backup2.file -L 'session1' -M 'media1" / > > > > > # > > > > So, I've got to Ctrl+C the process. > > > > Questions: > > 1) What could be the syntax problem in the above command? > > 2) Any examples for incremental xfsdump (non-interactive, i.e. run from > > cronjob) would be very welcome (and also comments about xfsrestore from > > these backups). > > My non-interactive backup is (fragment from a script): > > xfsdump -e -l $level -L "dump $lv at $day" - /$lv | gzip -v9 > $dest_file > > and it works without prompts. Combining this with LVM snapshots also > makes consistent backups. > Thanks Iustin. It's very usefull. So for non-interactive dumps I can use something like: # xfsdump -e -l 0 -L "dump hda1 of `uname -n` at `date +%F`" -M "file" -f /data/backup0.file / # xfsdump -e -l 1 -L "dump hda1 of `uname -n` at `date +%F`" -M "file" -f /data/backup1.file / # xfsdump -e -l 2 -L "dump hda1 of `uname -n` at `date +%F`" -M "file" -f /data/backup2.file / etc. The above is clear :) The question now is how to maintain these dumps accordingly to the inventory database in /var/lib/xfsdump/inventory. I believe that if I just delete dump file, the inventory database won't be updated, right? Lets say, I did level 0 dump on Sunday and a 1,2,3,4,5,6 level backups on the following days (all with different filenames o fcourse). So at the end of the week I end up with 7 dump files. I want this automatic procedure to continue to the next week with the same filenames, so no additional files would be added and no disk space would be wasted. I came up with this: -------------------- To remove the dump session in the inventory which is identified by the mount point, was created prior to the specified date, and media_lable Syntax: xfsinvutil -n -m media_label -M mount_point mm/dd/yyyy # DATE=`date +%m/%d/%Y`; xfsinvutil -n -m file0 -M vod:/ $DATE # rm /data/backup0.file I'll run the above 2 commands prior to xfsdump cronjobs. :) This is my solution. If you have any comments/suggestion you are very welcome. Best Regards, Leon Kolchinsky From owner-xfs@oss.sgi.com Mon Feb 26 10:37:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 26 Feb 2007 10:37:57 -0800 (PST) X-Spam-oss-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.2.0-pre1-r497472 Received: from foxengines.net (foxengines.net [69.5.8.162]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l1QIbpm7009274 for ; Mon, 26 Feb 2007 10:37:53 -0800 Received: (qmail 1550 invoked from network); 26 Feb 2007 18:09:49 -0000 X-Originating-IP: [75.67.148.163] Date: Mon, 26 Feb 2007 13:09:48 -0500 (EST) From: XFS User X-X-Sender: rfox@powerbook.localdomain Reply-To: sgixfs@foxengines.net To: xfs@oss.sgi.com Subject: 8.2TB->16.4TB xfs_growfs problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 10724 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sgixfs@foxengines.net Precedence: bulk X-list: xfs Content-Length: 1467 Lines: 35 Hello, I am experiencing a problem that I'm not sure how to resolve. I do not see this in the FAQ, nor have I found it in Bugzilla or the mailing lists, (they both seemed to be having search problems last week which prevented me from using them, I used Google to search into the site so I might've missed something). In summary, I have an 8.2TB filesystem on an 16.4TB LVM2 volume on a Linux 2.6.18 x86_64 with 4GB RAM. If I issue the 'xfs_growfs /mounted_volume' command, the command will complete without printing any errors and the command exits on 0. I can umount, then mount again, see the new 16TB volume. If for any reason, I run xfs_repair, all changes will be lost and the filesystem size will revert to it's original size (e.g it'll shrink back down to 8.2TB). On closer inspection I noticed that following the resize, the 0th superblock is updated with the new dblock size, but no other superblock seems to get updated. The first superblock (sb 1) second, third, and so on all report the original dblock value for the smaller filesystem. Furthermore, at the conclusion of the resize operation at the time that the filesystem attributes are printed, there is no line printed such as: "data blocks changed from to " Again, the xfs_growfs command does exit on 0 however. Can anyone provide any advice that I might try to straighten this out? I can provide much more detailed information on request. Thanks, Rich. From owner-xfs@oss.sgi.com Mon Feb 26 11:10:16 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 26 Feb 2007 11:10:20 -0800 (PST) X-Spam-oss-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, SPF_HELO_PASS autolearn=ham version=3.2.0-pre1-r497472 Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1QJAFm7015358 for ; Mon, 26 Feb 2007 11:10:16 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1QJ9uB9028814; Mon, 26 Feb 2007 14:09:56 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1QJ9tmW014231; Mon, 26 Feb 2007 14:09:55 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1QJ9rl0014277; Mon, 26 Feb 2007 14:09:55 -0500 Message-ID: <45E32FE0.4070204@sandeen.net> Date: Mon, 26 Feb 2007 13:07:12 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: sgixfs@foxengines.net CC: xfs@oss.sgi.com Subject: Re: 8.2TB->16.4TB xfs_growfs problem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10725 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1185 Lines: 32 XFS User wrote: > Hello, > > I am experiencing a problem that I'm not sure how to resolve. I do not see > this in the FAQ, nor have I found it in Bugzilla or the mailing lists, > (they both seemed to be having search problems last week which prevented > me from using them, I used Google to search into the site so I might've missed > something). > > In summary, I have an 8.2TB filesystem on an 16.4TB LVM2 volume on a > Linux 2.6.18 x86_64 with 4GB RAM. > If I issue the 'xfs_growfs /mounted_volume' command, the command will > complete without printing any errors and the command exits on 0. > > I can umount, then mount again, see the new 16TB volume. > > If for any reason, I run xfs_repair, all changes will be lost and the > filesystem size will revert to it's original size (e.g it'll shrink > back down to 8.2TB). There have been userspace & kernelspace fixes to growfs lately... TAKE 959492 - xfs_growfs should return an error on failure http://oss.sgi.com/archives/xfs/2006-12/msg00224.html TAKE 959978 - growing an XFS filesystem by more than 2TB is broken http://oss.sgi.com/archives/xfs/2007-01/msg00082.html I'd make sure you have those fixes, first. -Eric From owner-xfs@oss.sgi.com Tue Feb 27 23:43:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 27 Feb 2007 23:43:18 -0800 (PST) X-Spam-oss-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, J_CHICKENPOX_43 autolearn=no version=3.2.0-pre1-r499012 Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l1S7hC6p018433 for ; Tue, 27 Feb 2007 23:43:13 -0800 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l1S7h0tP000601 for ; Wed, 28 Feb 2007 16:43:11 +0900 (JST) Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l1S7XYGG004155 for ; Wed, 28 Feb 2007 16:33:34 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l1S7XXZ20581 for xfs@oss.sgi.com; Wed, 28 Feb 2007 16:33:33 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id l1S7XXL06601 for ; Wed, 28 Feb 2007 16:33:33 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20070228.153316.92101888 for ; Wed, 28 Feb 2007 15:33:17 +0900 Received: FROM tnessv1.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Wed Feb 28 15:33:16 2007 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by tnessv1.tnes.nec.co.jp (Postfix) with ESMTP id 6A238AE4B0 for ; Wed, 28 Feb 2007 16:33:29 +0900 (JST) Received: from TNESG9305.tnes.nec.co.jp (TNESG9305.bsd.tnes.nec.co.jp [10.1.104.199]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with SMTP id l1S7XWII002421 for ; Wed, 28 Feb 2007 16:33:32 +0900 Message-Id: <200702280733.AA05017@TNESG9305.tnes.nec.co.jp> Date: Wed, 28 Feb 2007 16:33:17 +0900 To: xfs@oss.sgi.com Subject: [PATCH] repquota does't report correct space usage From: Utako Kusaka MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=us-ascii X-archive-position: 10729 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: utako@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 2009 Lines: 61 Hi, repquota may report incorrect space usage when the filesystem is mounted repeatedly with different quota options. The cause of the problem is that xfs_qm_quotacheck() is not called because the `CHKD' flag in mp->m_qflags is not cleared until it is mounted with no quota option. This patch fixes it. Test case: mkfs.xfs -f /dev/sda6 mount -t xfs -o usrquota,grpquota /dev/sda6 mpnt/ setquota -u utako 3000 4000 0 0 /dev/sda6 setquota -u xfs 1500 2000 0 0 /dev/sda6 setquota -g users 1000 1500 0 0 /dev/sda6 repquota -ugv -a umount mpnt/ mount -t xfs -o usrquota /dev/sda6 mpnt/ xfs_mkfile 3m mpnt/file1 xfs_mkfile 1m mpnt/file2 chown utako mpnt/file1 chown xfs mpnt/file2 chgrp users mpnt/file* repquota -ugv -a umount mpnt/ mount -t xfs -o grpquota /dev/sda6 mpnt/ repquota -ugv -a rm mpnt/file1 repquota -ugv -a Result: *** Report for group quotas on device /dev/sda6 Block grace time: 7days; Inode grace time: 7days Block limits File limits Group used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 0 0 0 3 0 0 users +- 18014398509478912 1000 1500 7days 18446744073709551615 0 0 *** Status for group quotas on device /dev/sda6 Accounting: ON; Enforcement: ON Inode: #132 (2 blocks, 2 extents) Signed-off-by: Utako Kusaka --- --- linux-2.6.20-orgn/fs/xfs/quota/xfs_qm.c.orgn 2007-02-22 17:30:07.000000000 +0900 +++ linux-2.6.20/fs/xfs/xfs_qm.c 2007-02-22 17:30:58.000000000 +0900 @@ -1175,8 +1175,6 @@ xfs_qm_init_quotainfo( qinf->qi_dqperchunk = BBTOB(qinf->qi_dqchunklen); do_div(qinf->qi_dqperchunk, sizeof(xfs_dqblk_t)); - mp->m_qflags |= (mp->m_sb.sb_qflags & XFS_ALL_QUOTA_CHKD); - /* * We try to get the limits from the superuser's limits fields. * This is quite hacky, but it is standard quota practice.