From owner-xfs@oss.sgi.com Sun Jul 1 09:21:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jul 2007 09:21:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.6 required=5.0 tests=AWL,BAYES_99, DATE_IN_PAST_12_24,FH_HOST_EQ_D_D_D_D,FH_HOST_EQ_D_D_D_DB,RDNS_DYNAMIC autolearn=no version=3.2.0-pre1-r499012 Received: from mail.clusterfs.com (74-0-229-162.T1.lbdsl.net [74.0.229.162]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l61GLqtL001022 for ; Sun, 1 Jul 2007 09:21:54 -0700 Received: from localhost.adilger.int (CPE0080c816aec8-CM0011ae013d40.cpe.net.cable.rogers.com [74.122.210.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.clusterfs.com (Postfix) with ESMTP id 8F0374E4594; Sun, 1 Jul 2007 10:01:26 -0600 (MDT) Received: by localhost.adilger.int (Postfix, from userid 1000) id B77CF3FB2; Sat, 30 Jun 2007 12:52:46 -0400 (EDT) Date: Sat, 30 Jun 2007 12:52:46 -0400 From: Andreas Dilger To: Christoph Hellwig , "Amit K. Arora" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, David Chinner , suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070630165246.GA5159@schatzie.adilger.int> Mail-Followup-To: Christoph Hellwig , "Amit K. Arora" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, David Chinner , suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com References: <20070613235217.GS86004887@sgi.com> <20070614091458.GH5181@schatzie.adilger.int> <20070614120413.GD86004887@sgi.com> <20070614193347.GN5181@schatzie.adilger.int> <20070625132810.GA1951@amitarora.in.ibm.com> <20070625134500.GE1951@amitarora.in.ibm.com> <20070625150320.GA8686@amitarora.in.ibm.com> <20070625214626.GJ5181@schatzie.adilger.int> <20070626103247.GA19870@amitarora.in.ibm.com> <20070630102111.GB23568@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070630102111.GB23568@infradead.org> User-Agent: Mutt/1.4.1i X-GPG-Key: 1024D/0D35BED6 X-GPG-Fingerprint: 7A37 5D79 BF1B CECA D44F 8A29 A488 39F5 0D35 BED6 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12057 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adilger@clusterfs.com Precedence: bulk X-list: xfs Status: O Content-Length: 4240 Lines: 84 On Jun 30, 2007 11:21 +0100, Christoph Hellwig wrote: > On Tue, Jun 26, 2007 at 04:02:47PM +0530, Amit K. Arora wrote: > > Currently it is left on the file system implementation. In ext4, we do > > not undo preallocation if some error (say, ENOSPC) is hit. Hence it may > > end up with partial (pre)allocation. This is inline with dd and > > posix_fallocate, which also do not free the partially allocated space. > > I can't find anything in the specification of posix_fallocate > (http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html) > that tells what should happen to allocate blocks on error. > > But common sense would be to not leak disk space on failure of this > syscall, and this definitively should not be left up to the filesystem, > either we always leak it or always free it, and I'd strongly favour > the latter variant. I definitely agree that the behaviour should be specified part of the interface. The current behaviour of both ext4 and XFS is that the successful part of the unallocated extent is left in place when returning ENOSPC so we considered this the "consistent" behaviour. This is the same as e.g. sys_write() which does not remove the part of the write that was successful if ENOSPC is hit. I think this also makes sense for some usa cases, because application like PVR may want to preallocate approximately 30min of space, but if it gets only 25min worth then it can at least start using this while it also begins looking for and/or freeing old files. If the space is always freed on ENOSPC, then there may be a significant amount of work done and undone while the application is iterating over possible sizes until one works. It is easy for the application to use fstat() to see the blocks/size actually preallocated on failure, and explicitly request unallocation of this space if the outcome is undesirable. If you think that applications have a strong preference for both kinds of behaviour (e.g. database which requires the full allocation to succeed, unlike PVR application above) then this could be encoded into a @mode flag. > > > For FA_ZERO_SPACE - I'd think this would (IMHO) be the default - we > > > don't want to expose uninitialized disk blocks to userspace. I'm not > > > sure if this makes sense at all. > > This is the xfs unwritten extent behaviour. But anyway, the important bit > is uninitialized blocks should never ever leak to userspace, so there is > not need for the flag. I agree that we shouldn't need FA_ZERO_SPACE. If an application wants explicit zeros written to disk it can just do this with O_DIRECT writes or similar. > The more I think about it the more I'd prefer we would just put a simple > syscall in that implements nothing but the posix_fallocate(3) semantics > as defined in SuS, and then go on to brainstorm about advanced > preallocation / layout hint semantics. I don't think the current @mode flags introduce any significant complexity in the implementation, and in fact one of the reasons these came up in the first place was because David pointed out the XFS behaviour did NOT match with posix_fallocate() and we started getting strange semantics enforced by monolithic modes. IMHO, coding for and understanding the semantics of the monolithic modes is much more complex and less useful than the explicit flags. The @mode flags that are currently under consideration are (AFAIK): FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default allocate) */ FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change size) */ FA_FL_DEL_DATA 0x04 /* delete existing data in alloc range (default keep) */ Your concern about leaking space would imply: FA_FL_ERR_FREE 0x08 /* free preallocation on error (default keep prealloc) */ The other possible flags that were proposed, to avoid confusing backup and HSM applications when preallocated space is added or removed from a file (you don't want a backup app to re-backup a file that was migrated via HSM): FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */ FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */ Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From owner-xfs@oss.sgi.com Sun Jul 1 15:43:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jul 2007 15:43:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l61MhktL023774 for ; Sun, 1 Jul 2007 15:43:48 -0700 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 IAA15882; Mon, 2 Jul 2007 08:43:44 +1000 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 l61MhgeW8312111; Mon, 2 Jul 2007 08:43:43 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l61Mhd2U8303729; Mon, 2 Jul 2007 08:43:39 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 2 Jul 2007 08:43:39 +1000 From: David Chinner To: Eric Sandeen Cc: David Chinner , Just Marc , Barry Naujok , xfs@oss.sgi.com Subject: Re: xfs_fsr, performance related tweaks Message-ID: <20070701224339.GV31489@sgi.com> References: <4683ADEB.3010106@corky.net> <46841C60.5030207@sandeen.net> <4684A506.4030705@corky.net> <4684A98B.1030000@corky.net> <20070629070814.GR31489@sgi.com> <4684B1CC.60004@corky.net> <20070629074114.GS31489@sgi.com> <46869029.3040704@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46869029.3040704@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12058 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 Status: O Content-Length: 1251 Lines: 32 On Sat, Jun 30, 2007 at 01:17:29PM -0400, Eric Sandeen wrote: > David Chinner wrote: > > On Fri, Jun 29, 2007 at 08:16:28AM +0100, Just Marc wrote: > >> David, > >> > >> In my first post I already said something like that can be done but it's > >> just an ugly hack. Don't you think it would best be handled cleanly > >> and correctly by fsr itself? > > > > No, I don't - if you want files not to be defragmented, then you > > have to set the flags yourself in some way. You have a specific need > > that can be solved by some scripting to describe your defrag/no > > defrag policy. xfs_fsr has no place is setting defrag policy; it's > > function is simply to find and defrag files. > > I wouldn't mind seeing a way to tell fsr to not worry about defragging > some files based on current layout; say if the avg extent in the file is > > 100MB, or > 1G, don't bother... if today you have a 4.7G DVD iso image > in 3 extents (not bad) fsr will try to "fix" it for you right? That could be easily done with command line options, I think. Define the minimum extent length or number of extents we want files to have and ignore those that are outside that criteria. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Jul 1 15:56:20 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jul 2007 15:56:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l61MuHtL027953 for ; Sun, 1 Jul 2007 15:56:19 -0700 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 IAA16073; Mon, 2 Jul 2007 08:55:56 +1000 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 l61MtpeW8316854; Mon, 2 Jul 2007 08:55:52 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l61Mthxq8319074; Mon, 2 Jul 2007 08:55:43 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 2 Jul 2007 08:55:43 +1000 From: David Chinner To: Christoph Hellwig , "Amit K. Arora" , Andreas Dilger , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, David Chinner , suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070701225543.GW31489@sgi.com> References: <20070613235217.GS86004887@sgi.com> <20070614091458.GH5181@schatzie.adilger.int> <20070614120413.GD86004887@sgi.com> <20070614193347.GN5181@schatzie.adilger.int> <20070625132810.GA1951@amitarora.in.ibm.com> <20070625134500.GE1951@amitarora.in.ibm.com> <20070625150320.GA8686@amitarora.in.ibm.com> <20070625214626.GJ5181@schatzie.adilger.int> <20070626103247.GA19870@amitarora.in.ibm.com> <20070630102111.GB23568@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070630102111.GB23568@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12059 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 Status: O Content-Length: 1732 Lines: 40 On Sat, Jun 30, 2007 at 11:21:11AM +0100, Christoph Hellwig wrote: > On Tue, Jun 26, 2007 at 04:02:47PM +0530, Amit K. Arora wrote: > > > Can you clarify - what is the current behaviour when ENOSPC (or some other > > > error) is hit? Does it keep the current fallocate() or does it free it? > > > > Currently it is left on the file system implementation. In ext4, we do > > not undo preallocation if some error (say, ENOSPC) is hit. Hence it may > > end up with partial (pre)allocation. This is inline with dd and > > posix_fallocate, which also do not free the partially allocated space. > > I can't find anything in the specification of posix_fallocate > (http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html) > that tells what should happen to allocate blocks on error. Yeah, and AFAICT glibc leaves them behind ATM. > But common sense would be to not leak disk space on failure of this > syscall, and this definitively should not be left up to the filesystem, > either we always leak it or always free it, and I'd strongly favour > the latter variant. We can't simply walk the range an remove unwritten extents, as some of them may have been present before the fallocate() call. That makes it extremely difficult to undo a failed call and not remove more pre-existing pre-allocations. Given the current behaviour for posix_fallocate() in glibc, I think that retaining the same error semantic and punting the cleanup to userspace (where the app will fail with ENOSPC anyway) is the only sane thing we can do here. Trying to undo this in the kernel leads to lots of extra rarely used code in error handling paths... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jul 2 02:40:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 02:40:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l629eYtL014130 for ; Mon, 2 Jul 2007 02:40:36 -0700 Received: from [10.20.1.116] (discovery.suse.cz [10.20.1.116]) by mail.suse.cz (Postfix) with ESMTP id 3FF01628194; Mon, 2 Jul 2007 11:40:34 +0200 (CEST) Message-ID: <4688C812.9020200@suse.cz> Date: Mon, 02 Jul 2007 11:40:34 +0200 From: Michal Marek User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1) Gecko/20061107 SUSE/1.0.99-26 SeaMonkey/1.1b MIME-Version: 1.0 To: David Chinner Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [patch 3/3] Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode References: <20070619132549.266927601@suse.cz> <20070619132726.893544847@suse.cz> <20070628034957.GE989688@sgi.com> In-Reply-To: <20070628034957.GE989688@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12060 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmarek@suse.cz Precedence: bulk X-list: xfs Status: O Content-Length: 1420 Lines: 32 David Chinner wrote: > On Tue, Jun 19, 2007 at 03:25:52PM +0200, mmarek@suse.cz wrote: >> +static int xfs_bulkstat_one_compat( >> + xfs_mount_t *mp, /* mount point for filesystem */ >> + xfs_ino_t ino, /* inode number to get data for */ >> + void __user *buffer, /* buffer to place output in */ >> + int ubsize, /* size of buffer */ >> + void *private_data, /* my private data */ >> + xfs_daddr_t bno, /* starting bno of inode cluster */ >> + int *ubused, /* bytes used by me */ >> + void *dibuff, /* on-disk inode buffer */ >> + int *stat) /* BULKSTAT_RV_... */ > > Hmmm - this is almost all duplicated code. It's pretty much what I > described, but maybe not /quite/ what I had in mind here. It's a > *big* improvement on the first version, but it seems now that the > only real difference xfs_bulkstat_one() and > xfs_bulkstat_one_compat() is copy_to_user() vs the discrete put_user > calls. > > I think we can remove xfs_bulkstat_one_compat() completely by using > the same method you used with the xfs_inumber_fmt functions. You mean xfs_ioc_bulkstat_compat() -> native xfs_bulkstat() -> native xfs_bulkstat_one() -> a compat output formatter, so a pointer-to-function passed to pointer-to-function? ;) I could (ab)use the void *private_data arg which xfs_bulkstat passes unmodified to the formatter; xfs_bulkstat_one() doesn't make use of it atm. I'll try it and post the result in a while. Michal From owner-xfs@oss.sgi.com Mon Jul 2 03:58:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 03:58:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=AWL,BAYES_95 autolearn=no version=3.2.0-pre1-r499012 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l62Aw6tL011017 for ; Mon, 2 Jul 2007 03:58:08 -0700 Received: by wa-out-1112.google.com with SMTP id k22so2278439waf for ; Mon, 02 Jul 2007 03:58:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=H4rkDpUMOGG0f5cDwKjEEGNlD9v/fMo1y7ddITW1CDt9qQ9QD+IsBhCmrqDO9KfXMwlKFgWLvADBkNZfwFjcldKeVloOU10zw+TKEc8O9gjNA7o6VJTF+gODV+Dr0C27qdOxPB4VfH6SWHRUIVmWUFJAOCn4E+R+7dayE2stvNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=I8z+D4KKOX/EPCRjkyp3sNVXfaz0k+1N8z96T0QMslU3138IHnF+UFFuc+FLpc0l5SKdorSg9XE5cqckcRE8h3F0L8RhtdUkYYBCeuXGhqnLTHUxHmzIH744d/SayE2GxSiQxFlEkZorq8UPwTtTf2NMe0DVARGCfaW4Jwp3owQ= Received: by 10.115.58.1 with SMTP id l1mr4986146wak.1183373888640; Mon, 02 Jul 2007 03:58:08 -0700 (PDT) Received: from htj.dyndns.org ( [221.139.199.46]) by mx.google.com with ESMTP id l27sm12944334waf.2007.07.02.03.58.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jul 2007 03:58:07 -0700 (PDT) Received: from [192.168.2.5] (wtj [192.168.2.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tj@htj.dyndns.org) by htj.dyndns.org (Postfix) with ESMTP id E412323D416D; Mon, 2 Jul 2007 19:58:02 +0900 (KST) Message-ID: <4688D9F2.6020000@gmail.com> Date: Mon, 02 Jul 2007 19:56:50 +0900 From: Tejun Heo User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: David Greaves CC: David Chinner , David Robinson , LVM general discussion and development , "'linux-kernel@vger.kernel.org'" , xfs@oss.sgi.com, linux-pm , LinuxRaid , "Rafael J. Wysocki" Subject: Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume References: <46744065.6060605@dgreaves.com> <4674645F.5000906@gmail.com> <46751D37.5020608@dgreaves.com> <4676390E.6010202@dgreaves.com> <20070618145007.GE85884050@sgi.com> <4676D97E.4000403@dgreaves.com> <4677A0C7.4000306@dgreaves.com> <4677A596.7090404@gmail.com> <4677E496.3080506@dgreaves.com> <4678DF56.1020903@gmail.com> <467ABE25.7060303@dgreaves.com> <4684C0DD.4080702@dgreaves.com> In-Reply-To: <4684C0DD.4080702@dgreaves.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12061 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: htejun@gmail.com Precedence: bulk X-list: xfs Status: O Content-Length: 672 Lines: 19 David Greaves wrote: >> Tejun Heo wrote: >>> It's really weird tho. The PHY RDY status changed events are coming >>> from the device which is NOT used while resuming > > There is an obvious problem there though Tejun (the errors even when sda > isn't involved in the OS boot) - can I start another thread about that > issue/bug later? I need to reshuffle partitions so I'd rather get the > hibernate working first and then go back to it if that's OK? Yeah, sure. The problem is that we don't know whether or how those two are related. It would be great if there's a way to verify memory image read from hibernation is intact. Rafael, any ideas? Thanks. -- tejun From owner-xfs@oss.sgi.com Mon Jul 2 04:47:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 04:47:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l62BlNtL028160 for ; Mon, 2 Jul 2007 04:47:26 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l62BlMLP011478 for ; Mon, 2 Jul 2007 07:47:22 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l62BlMk2534102 for ; Mon, 2 Jul 2007 07:47:22 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l62BlMmO027492 for ; Mon, 2 Jul 2007 07:47:22 -0400 Received: from amitarora.in.ibm.com (amitarora.in.ibm.com [9.124.31.198]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l62BlKC3027432; Mon, 2 Jul 2007 07:47:21 -0400 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 1EBB994EC8; Mon, 2 Jul 2007 17:17:34 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l62BlU5d029919; Mon, 2 Jul 2007 17:17:30 +0530 Date: Mon, 2 Jul 2007 17:17:30 +0530 From: "Amit K. Arora" To: David Chinner Cc: Christoph Hellwig , Andreas Dilger , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070702114730.GA21966@amitarora.in.ibm.com> References: <20070614091458.GH5181@schatzie.adilger.int> <20070614120413.GD86004887@sgi.com> <20070614193347.GN5181@schatzie.adilger.int> <20070625132810.GA1951@amitarora.in.ibm.com> <20070625134500.GE1951@amitarora.in.ibm.com> <20070625150320.GA8686@amitarora.in.ibm.com> <20070625214626.GJ5181@schatzie.adilger.int> <20070626103247.GA19870@amitarora.in.ibm.com> <20070630102111.GB23568@infradead.org> <20070701225543.GW31489@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070701225543.GW31489@sgi.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12062 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aarora@linux.vnet.ibm.com Precedence: bulk X-list: xfs Status: O Content-Length: 2649 Lines: 55 On Mon, Jul 02, 2007 at 08:55:43AM +1000, David Chinner wrote: > On Sat, Jun 30, 2007 at 11:21:11AM +0100, Christoph Hellwig wrote: > > On Tue, Jun 26, 2007 at 04:02:47PM +0530, Amit K. Arora wrote: > > > > Can you clarify - what is the current behaviour when ENOSPC (or some other > > > > error) is hit? Does it keep the current fallocate() or does it free it? > > > > > > Currently it is left on the file system implementation. In ext4, we do > > > not undo preallocation if some error (say, ENOSPC) is hit. Hence it may > > > end up with partial (pre)allocation. This is inline with dd and > > > posix_fallocate, which also do not free the partially allocated space. > > > > I can't find anything in the specification of posix_fallocate > > (http://www.opengroup.org/onlinepubs/009695399/functions/posix_fallocate.html) > > that tells what should happen to allocate blocks on error. > > Yeah, and AFAICT glibc leaves them behind ATM. Yes, it does. > > But common sense would be to not leak disk space on failure of this > > syscall, and this definitively should not be left up to the filesystem, > > either we always leak it or always free it, and I'd strongly favour > > the latter variant. I would not call it a "leak", since the blocks which got allocated as part of the partial success of the fallocate syscall can be strictly accounted for (i.e. they are assigned to a particular inode). And these can be freed by the application, using a suitable @mode of fallocate. > We can't simply walk the range an remove unwritten extents, as some > of them may have been present before the fallocate() call. That > makes it extremely difficult to undo a failed call and not remove > more pre-existing pre-allocations. Same is true for ext4 too. It is very difficult to keep track of which uninitialized (unwritten) extents got allocated as part of the current syscall. This is because, as David mentions, some of them might be already present; and also because some of the older ones may have got merged with the *new* uninitialized/unwritten extents as part of the current syscall. > Given the current behaviour for posix_fallocate() in glibc, I think > that retaining the same error semantic and punting the cleanup to > userspace (where the app will fail with ENOSPC anyway) is the only > sane thing we can do here. Trying to undo this in the kernel leads > to lots of extra rarely used code in error handling paths... Right. This gives applications the free hand if they really want to use the partially preallocated space, OR they want to free it; without introducing additional complexity in the kernel. -- Regards, Amit Arora From owner-xfs@oss.sgi.com Mon Jul 2 06:02:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 06:02:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l62D1xtL024696 for ; Mon, 2 Jul 2007 06:02:01 -0700 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 XAA04447; Mon, 2 Jul 2007 23:01:55 +1000 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 l62D1reW8795179; Mon, 2 Jul 2007 23:01:54 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l62D1ora8796452; Mon, 2 Jul 2007 23:01:50 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 2 Jul 2007 23:01:50 +1000 From: David Chinner To: Szabolcs Illes Cc: xfs@oss.sgi.com Subject: Re: After reboot fs with barrier faster deletes then fs with nobarrier Message-ID: <20070702130150.GK989688@sgi.com> References: <20070629001648.GD31489@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-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12063 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 Status: O Content-Length: 862 Lines: 36 On Fri, Jun 29, 2007 at 01:01:36PM +0100, Szabolcs Illes wrote: > on my desktop pc: > > WCE=1 hot-cache/cold cache nobarrier is faster. same results as I got. After reboot, nobarrier is way slow. > WCE=0 hot-cache/cold-cache is pretty much identical. Same results I got. After reboot, nobarrier is way slow. > for cold cache I used: echo 3 > /proc/sys/vm/drop_caches Same here. > it looks like this machine is only affected after reboot, maybe the hdd > has more cache, then the hdd in my 3 years old laptop. > on my laptop it was enought to clear the kernel cache. > > How did you do your "cold" tests? reboot or drop_caches? drop_caches. So there definitely appears to be something about a reboot that is causing an issue here. I'll see if I can reproduce it here. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jul 2 07:01:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 07:01:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from ogre.sisk.pl (ogre.sisk.pl [217.79.144.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l62E1mtL008879 for ; Mon, 2 Jul 2007 07:01:51 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id B322E4FBE9; Mon, 2 Jul 2007 15:38:19 +0200 (CEST) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13492-01; Mon, 2 Jul 2007 15:38:19 +0200 (CEST) Received: from [192.168.144.104] (iftwlan0.fuw.edu.pl [193.0.83.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id 16F624A67B; Mon, 2 Jul 2007 15:38:19 +0200 (CEST) From: "Rafael J. Wysocki" To: Tejun Heo Subject: Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume Date: Mon, 2 Jul 2007 16:08:55 +0200 User-Agent: KMail/1.9.5 Cc: David Greaves , David Chinner , David Robinson , LVM general discussion and development , "'linux-kernel@vger.kernel.org'" , xfs@oss.sgi.com, linux-pm , LinuxRaid References: <46744065.6060605@dgreaves.com> <4684C0DD.4080702@dgreaves.com> <4688D9F2.6020000@gmail.com> In-Reply-To: <4688D9F2.6020000@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707021608.56616.rjw@sisk.pl> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux X-Virus-Status: Clean X-archive-position: 12064 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rjw@sisk.pl Precedence: bulk X-list: xfs Status: O Content-Length: 1014 Lines: 26 On Monday, 2 July 2007 12:56, Tejun Heo wrote: > David Greaves wrote: > >> Tejun Heo wrote: > >>> It's really weird tho. The PHY RDY status changed events are coming > >>> from the device which is NOT used while resuming > > > > There is an obvious problem there though Tejun (the errors even when sda > > isn't involved in the OS boot) - can I start another thread about that > > issue/bug later? I need to reshuffle partitions so I'd rather get the > > hibernate working first and then go back to it if that's OK? > > Yeah, sure. The problem is that we don't know whether or how those two > are related. It would be great if there's a way to verify memory image > read from hibernation is intact. Rafael, any ideas? Well, s2disk has an option to compute an MD5 checksum of the image during the hibernation and verify it while reading the image. Still, s2disk/resume aren't very easy to install and configure ... Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth From owner-xfs@oss.sgi.com Mon Jul 2 07:32:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 07:32:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=5.0 tests=AWL,BAYES_80 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l62EWQtL019316 for ; Mon, 2 Jul 2007 07:32:28 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 518FCE711F; Mon, 2 Jul 2007 15:32:08 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id yWSSUrySkUQ7; Mon, 2 Jul 2007 15:31:05 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 84F1FE711A; Mon, 2 Jul 2007 15:32:07 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1I5Mx0-00055N-HT; Mon, 02 Jul 2007 15:32:26 +0100 Message-ID: <46890C7A.5040008@dgreaves.com> Date: Mon, 02 Jul 2007 15:32:26 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070618) MIME-Version: 1.0 To: "Rafael J. Wysocki" Cc: Tejun Heo , David Chinner , David Robinson , LVM general discussion and development , "'linux-kernel@vger.kernel.org'" , xfs@oss.sgi.com, linux-pm , LinuxRaid Subject: Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume References: <46744065.6060605@dgreaves.com> <4684C0DD.4080702@dgreaves.com> <4688D9F2.6020000@gmail.com> <200707021608.56616.rjw@sisk.pl> In-Reply-To: <200707021608.56616.rjw@sisk.pl> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12065 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Status: O Content-Length: 1215 Lines: 31 Rafael J. Wysocki wrote: > On Monday, 2 July 2007 12:56, Tejun Heo wrote: >> David Greaves wrote: >>>> Tejun Heo wrote: >>>>> It's really weird tho. The PHY RDY status changed events are coming >>>>> from the device which is NOT used while resuming >>> There is an obvious problem there though Tejun (the errors even when sda >>> isn't involved in the OS boot) - can I start another thread about that >>> issue/bug later? I need to reshuffle partitions so I'd rather get the >>> hibernate working first and then go back to it if that's OK? >> Yeah, sure. The problem is that we don't know whether or how those two >> are related. It would be great if there's a way to verify memory image >> read from hibernation is intact. Rafael, any ideas? > > Well, s2disk has an option to compute an MD5 checksum of the image during > the hibernation and verify it while reading the image. (Assuming you mean the mainline version) Sounds like a good think to try next... Couldn't see anything on this in ../Documentation/power/* How do I enable it? > Still, s2disk/resume > aren't very easy to install and configure ... I have it working fine on 2 other machines now so that doesn't appear to be a problem. David From owner-xfs@oss.sgi.com Mon Jul 2 08:05:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 08:05:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.suse.cz (styx.suse.cz [82.119.242.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l62F58tL029032 for ; Mon, 2 Jul 2007 08:05:09 -0700 Received: from discovery.suse.cz (discovery.suse.cz [10.20.1.116]) by mail.suse.cz (Postfix) with ESMTP id E0F3C146C0BE; Mon, 2 Jul 2007 17:05:09 +0200 (CEST) Received: by discovery.suse.cz (Postfix, from userid 10020) id C684282E94; Mon, 2 Jul 2007 17:05:09 +0200 (CEST) Date: Mon, 2 Jul 2007 17:05:09 +0200 From: Michal Marek To: David Chinner Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [patch 3/3] Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode (try3) Message-ID: <20070702150509.GA32192@discovery.suse.cz> References: <20070619132549.266927601@suse.cz> <20070619132726.893544847@suse.cz> <20070628034957.GE989688@sgi.com> <4688C812.9020200@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4688C812.9020200@suse.cz> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12066 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mmarek@suse.cz Precedence: bulk X-list: xfs Status: O Content-Length: 14138 Lines: 453 On Mon, Jul 02, 2007 at 11:40:34AM +0200, Michal Marek wrote: > David Chinner wrote: > > I think we can remove xfs_bulkstat_one_compat() completely by using > > the same method you used with the xfs_inumber_fmt functions. > > You mean xfs_ioc_bulkstat_compat() -> native xfs_bulkstat() -> native > xfs_bulkstat_one() -> a compat output formatter, so a > pointer-to-function passed to pointer-to-function? ;) I could (ab)use > the void *private_data arg which xfs_bulkstat passes unmodified to the > formatter; xfs_bulkstat_one() doesn't make use of it atm. I'll try it > and post the result in a while. Hi David, what about this one? It about 30 lines shorter now :) Subject: Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode * 32bit struct xfs_fsop_bulkreq has different size and layout of members, no matter the alignment. Move the code out of the #else branch (why was it there in the first place?). Define _32 variants of the ioctl constants. * 32bit struct xfs_bstat is different because of time_t and on i386 because of different padding. Make xfs_bulkstat_one() accept a custom "output formater" in the private_data argument which takes care of the xfs_bulkstat_one_compat() that takes care of the different layout in the compat case. * i386 struct xfs_inogrp has different padding. Add a similar "output formater" mecanism to xfs_inumbers(). Signed-off-by: Michal Marek --- fs/xfs/linux-2.6/xfs_ioctl.c | 2 fs/xfs/linux-2.6/xfs_ioctl32.c | 221 ++++++++++++++++++++++++++++++++++++----- fs/xfs/xfs_itable.c | 41 ++++++- fs/xfs/xfs_itable.h | 20 +++ 4 files changed, 252 insertions(+), 32 deletions(-) --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_ioctl32.c +++ linux-2.6/fs/xfs/linux-2.6/xfs_ioctl32.c @@ -28,12 +28,27 @@ #include "xfs_vfs.h" #include "xfs_vnode.h" #include "xfs_dfrag.h" +#include "xfs_sb.h" +#include "xfs_log.h" +#include "xfs_trans.h" +#include "xfs_dmapi.h" +#include "xfs_mount.h" +#include "xfs_inum.h" +#include "xfs_bmap_btree.h" +#include "xfs_dir2.h" +#include "xfs_dir2_sf.h" +#include "xfs_attr_sf.h" +#include "xfs_dinode.h" +#include "xfs_itable.h" +#include "xfs_error.h" +#include "xfs_inode.h" #define _NATIVE_IOC(cmd, type) \ _IOC(_IOC_DIR(cmd), _IOC_TYPE(cmd), _IOC_NR(cmd), sizeof(type)) #if defined(CONFIG_IA64) || defined(CONFIG_X86_64) #define BROKEN_X86_ALIGNMENT +#define _PACKED __attribute__((packed)) /* on ia32 l_start is on a 32-bit boundary */ typedef struct xfs_flock64_32 { __s16 l_type; @@ -111,35 +126,196 @@ STATIC unsigned long xfs_ioctl32_geom_v1 return (unsigned long)p; } +typedef struct compat_xfs_inogrp { + __u64 xi_startino; /* starting inode number */ + __s32 xi_alloccount; /* # bits set in allocmask */ + __u64 xi_allocmask; /* mask of allocated inodes */ +} __attribute__((packed)) compat_xfs_inogrp_t; + +STATIC int xfs_inumbers_fmt_compat( + void __user *ubuffer, + const xfs_inogrp_t *buffer, + long count, + long *written) +{ + compat_xfs_inogrp_t *p32 = ubuffer; + long i; + + for (i = 0; i < count; i++) { + if (put_user(buffer[i].xi_startino, &p32[i].xi_startino) || + put_user(buffer[i].xi_alloccount, &p32[i].xi_alloccount) || + put_user(buffer[i].xi_allocmask, &p32[i].xi_allocmask)) + return -EFAULT; + } + *written = count * sizeof(*p32); + return 0; +} + #else -typedef struct xfs_fsop_bulkreq32 { +#define xfs_inumbers_fmt_compat xfs_inumbers_fmt +#define _PACKED + +#endif + +/* XFS_IOC_FSBULKSTAT and friends */ + +typedef struct compat_xfs_bstime { + __s32 tv_sec; /* seconds */ + __s32 tv_nsec; /* and nanoseconds */ +} compat_xfs_bstime_t; + +STATIC int xfs_bstime_store_compat( + compat_xfs_bstime_t __user *p32, + const xfs_bstime_t *p) +{ + __s32 sec32; + + sec32 = p->tv_sec; + if (put_user(sec32, &p32->tv_sec) || + put_user(p->tv_nsec, &p32->tv_nsec)) + return -EFAULT; + return 0; +} + +typedef struct compat_xfs_bstat { + __u64 bs_ino; /* inode number */ + __u16 bs_mode; /* type and mode */ + __u16 bs_nlink; /* number of links */ + __u32 bs_uid; /* user id */ + __u32 bs_gid; /* group id */ + __u32 bs_rdev; /* device value */ + __s32 bs_blksize; /* block size */ + __s64 bs_size; /* file size */ + compat_xfs_bstime_t bs_atime; /* access time */ + compat_xfs_bstime_t bs_mtime; /* modify time */ + compat_xfs_bstime_t bs_ctime; /* inode change time */ + int64_t bs_blocks; /* number of blocks */ + __u32 bs_xflags; /* extended flags */ + __s32 bs_extsize; /* extent size */ + __s32 bs_extents; /* number of extents */ + __u32 bs_gen; /* generation count */ + __u16 bs_projid; /* project id */ + unsigned char bs_pad[14]; /* pad space, unused */ + __u32 bs_dmevmask; /* DMIG event mask */ + __u16 bs_dmstate; /* DMIG state info */ + __u16 bs_aextents; /* attribute number of extents */ +} _PACKED compat_xfs_bstat_t; + +STATIC int xfs_bulkstat_one_fmt_compat( + void __user *ubuffer, + const xfs_bstat_t *buffer) +{ + compat_xfs_bstat_t __user *p32 = ubuffer; + + if (put_user(buffer->bs_ino, &p32->bs_ino) || + put_user(buffer->bs_mode, &p32->bs_mode) || + put_user(buffer->bs_nlink, &p32->bs_nlink) || + put_user(buffer->bs_uid, &p32->bs_uid) || + put_user(buffer->bs_gid, &p32->bs_gid) || + put_user(buffer->bs_rdev, &p32->bs_rdev) || + put_user(buffer->bs_blksize, &p32->bs_blksize) || + put_user(buffer->bs_size, &p32->bs_size) || + xfs_bstime_store_compat(&p32->bs_atime, &buffer->bs_atime) || + xfs_bstime_store_compat(&p32->bs_mtime, &buffer->bs_mtime) || + xfs_bstime_store_compat(&p32->bs_ctime, &buffer->bs_ctime) || + put_user(buffer->bs_blocks, &p32->bs_blocks) || + put_user(buffer->bs_xflags, &p32->bs_xflags) || + put_user(buffer->bs_extsize, &p32->bs_extsize) || + put_user(buffer->bs_extents, &p32->bs_extents) || + put_user(buffer->bs_gen, &p32->bs_gen) || + put_user(buffer->bs_projid, &p32->bs_projid) || + put_user(buffer->bs_dmevmask, &p32->bs_dmevmask) || + put_user(buffer->bs_dmstate, &p32->bs_dmstate) || + put_user(buffer->bs_aextents, &p32->bs_aextents)) + return -EFAULT; + return sizeof(*p32); +} + + + +typedef struct compat_xfs_fsop_bulkreq { compat_uptr_t lastip; /* last inode # pointer */ __s32 icount; /* count of entries in buffer */ compat_uptr_t ubuffer; /* user buffer for inode desc. */ - __s32 ocount; /* output count pointer */ -} xfs_fsop_bulkreq32_t; + compat_uptr_t ocount; /* output count pointer */ +} compat_xfs_fsop_bulkreq_t; -STATIC unsigned long -xfs_ioctl32_bulkstat( - unsigned long arg) +#define XFS_IOC_FSBULKSTAT_32 \ + _IOWR('X', 101, struct compat_xfs_fsop_bulkreq) +#define XFS_IOC_FSBULKSTAT_SINGLE_32 \ + _IOWR('X', 102, struct compat_xfs_fsop_bulkreq) +#define XFS_IOC_FSINUMBERS_32 \ + _IOWR('X', 103, struct compat_xfs_fsop_bulkreq) + +/* copied from xfs_ioctl.c */ +STATIC int +xfs_ioc_bulkstat_compat( + xfs_mount_t *mp, + unsigned int cmd, + void __user *arg) { - xfs_fsop_bulkreq32_t __user *p32 = (void __user *)arg; - xfs_fsop_bulkreq_t __user *p = compat_alloc_user_space(sizeof(*p)); + compat_xfs_fsop_bulkreq_t __user *p32 = (void __user *)arg; u32 addr; + xfs_fsop_bulkreq_t bulkreq; + int count; /* # of records returned */ + xfs_ino_t inlast; /* last inode number */ + int done; + int error; + + /* done = 1 if there are more stats to get and if bulkstat */ + /* should be called again (unused here, but used in dmapi) */ + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + if (XFS_FORCED_SHUTDOWN(mp)) + return -XFS_ERROR(EIO); - if (get_user(addr, &p32->lastip) || - put_user(compat_ptr(addr), &p->lastip) || - copy_in_user(&p->icount, &p32->icount, sizeof(s32)) || - get_user(addr, &p32->ubuffer) || - put_user(compat_ptr(addr), &p->ubuffer) || - get_user(addr, &p32->ocount) || - put_user(compat_ptr(addr), &p->ocount)) + if (get_user(addr, &p32->lastip)) return -EFAULT; + bulkreq.lastip = compat_ptr(addr); + if (get_user(bulkreq.icount, &p32->icount) || + get_user(addr, &p32->ubuffer)) + return -EFAULT; + bulkreq.ubuffer = compat_ptr(addr); + if (get_user(addr, &p32->ocount)) + return -EFAULT; + bulkreq.ocount = compat_ptr(addr); - return (unsigned long)p; + if (copy_from_user(&inlast, bulkreq.lastip, sizeof(__s64))) + return -XFS_ERROR(EFAULT); + + if ((count = bulkreq.icount) <= 0) + return -XFS_ERROR(EINVAL); + + if (cmd == XFS_IOC_FSINUMBERS) + error = xfs_inumbers(mp, &inlast, &count, + bulkreq.ubuffer, xfs_inumbers_fmt_compat); + else { + /* declare a var to get a warning in case the type changes */ + bulkstat_one_fmt_pf formatter = xfs_bulkstat_one_fmt_compat; + error = xfs_bulkstat(mp, &inlast, &count, + xfs_bulkstat_one, formatter, + sizeof(compat_xfs_bstat_t), bulkreq.ubuffer, + BULKSTAT_FG_QUICK, &done); + } + if (error) + return -error; + + if (bulkreq.ocount != NULL) { + if (copy_to_user(bulkreq.lastip, &inlast, + sizeof(xfs_ino_t))) + return -XFS_ERROR(EFAULT); + + if (copy_to_user(bulkreq.ocount, &count, sizeof(count))) + return -XFS_ERROR(EFAULT); + } + + return 0; } -#endif + + typedef struct compat_xfs_fsop_handlereq { __u32 fd; /* fd for FD_TO_HANDLE */ @@ -261,12 +437,13 @@ xfs_compat_ioctl( case XFS_IOC_SWAPEXT: break; - case XFS_IOC_FSBULKSTAT_SINGLE: - case XFS_IOC_FSBULKSTAT: - case XFS_IOC_FSINUMBERS: - arg = xfs_ioctl32_bulkstat(arg); - break; #endif + case XFS_IOC_FSBULKSTAT_32: + case XFS_IOC_FSBULKSTAT_SINGLE_32: + case XFS_IOC_FSINUMBERS_32: + cmd = _NATIVE_IOC(cmd, struct xfs_fsop_bulkreq); + return xfs_ioc_bulkstat_compat(XFS_BHVTOI(VNHEAD(vp))->i_mount, + cmd, (void*)arg); case XFS_IOC_FD_TO_HANDLE_32: case XFS_IOC_PATH_TO_HANDLE_32: case XFS_IOC_PATH_TO_FSHANDLE_32: --- linux-2.6.orig/fs/xfs/xfs_itable.h +++ linux-2.6/fs/xfs/xfs_itable.h @@ -69,6 +69,10 @@ xfs_bulkstat_single( char __user *buffer, int *done); +typedef int (*bulkstat_one_fmt_pf)( /* used size in bytes or negative error */ + void __user *ubuffer, /* buffer to write to */ + const xfs_bstat_t *buffer); /* buffer to read from */ + int xfs_bulkstat_one( xfs_mount_t *mp, @@ -86,11 +90,25 @@ xfs_internal_inum( xfs_mount_t *mp, xfs_ino_t ino); +typedef int (*inumbers_fmt_pf)( + void __user *ubuffer, /* buffer to write to */ + const xfs_inogrp_t *buffer, /* buffer to read from */ + long count, /* # of elements to read */ + long *written); /* # of bytes written */ + +int +xfs_inumbers_fmt( + void __user *ubuffer, /* buffer to write to */ + const xfs_inogrp_t *buffer, /* buffer to read from */ + long count, /* # of elements to read */ + long *written); /* # of bytes written */ + int /* error status */ xfs_inumbers( xfs_mount_t *mp, /* mount point for filesystem */ xfs_ino_t *last, /* last inode returned */ int *count, /* size of buffer/count returned */ - xfs_inogrp_t __user *buffer);/* buffer with inode info */ + void __user *buffer, /* buffer with inode info */ + inumbers_fmt_pf formatter); #endif /* __XFS_ITABLE_H__ */ --- linux-2.6.orig/fs/xfs/xfs_itable.c +++ linux-2.6/fs/xfs/xfs_itable.c @@ -202,6 +202,16 @@ xfs_bulkstat_one_dinode( return 0; } +STATIC int +xfs_bulkstat_one_fmt( + void __user *ubuffer, + const xfs_bstat_t *buffer) +{ + if (copy_to_user(ubuffer, buffer, sizeof(*buffer))) + return -EFAULT; + return sizeof(*buffer); +} + /* * Return stat information for one inode. * Return 0 if ok, else errno. @@ -221,6 +231,7 @@ xfs_bulkstat_one( xfs_bstat_t *buf; /* return buffer */ int error = 0; /* error value */ xfs_dinode_t *dip; /* dinode inode pointer */ + bulkstat_one_fmt_pf formatter = private_data ? : xfs_bulkstat_one_fmt; dip = (xfs_dinode_t *)dibuff; *stat = BULKSTAT_RV_NOTHING; @@ -243,14 +254,14 @@ xfs_bulkstat_one( xfs_bulkstat_one_dinode(mp, ino, dip, buf); } - if (copy_to_user(buffer, buf, sizeof(*buf))) { + if ((error = formatter(buffer, buf)) < 0) { error = EFAULT; goto out_free; } *stat = BULKSTAT_RV_DIDONE; if (ubused) - *ubused = sizeof(*buf); + *ubused = error; out_free: kmem_free(buf, sizeof(*buf)); @@ -748,6 +759,19 @@ xfs_bulkstat_single( return 0; } +int +xfs_inumbers_fmt( + void __user *ubuffer, /* buffer to write to */ + const xfs_inogrp_t *buffer, /* buffer to read from */ + long count, /* # of elements to read */ + long *written) /* # of bytes written */ +{ + if (copy_to_user(ubuffer, buffer, count * sizeof(*buffer))) + return -EFAULT; + *written = count * sizeof(*buffer); + return 0; +} + /* * Return inode number table for the filesystem. */ @@ -756,7 +780,8 @@ xfs_inumbers( xfs_mount_t *mp, /* mount point for filesystem */ xfs_ino_t *lastino, /* last inode returned */ int *count, /* size of buffer/count returned */ - xfs_inogrp_t __user *ubuffer)/* buffer with inode descriptions */ + void __user *ubuffer,/* buffer with inode descriptions */ + inumbers_fmt_pf formatter) { xfs_buf_t *agbp; xfs_agino_t agino; @@ -835,12 +860,12 @@ xfs_inumbers( bufidx++; left--; if (bufidx == bcount) { - if (copy_to_user(ubuffer, buffer, - bufidx * sizeof(*buffer))) { + long written; + if (formatter(ubuffer, buffer, bufidx, &written)) { error = XFS_ERROR(EFAULT); break; } - ubuffer += bufidx; + ubuffer += written; *count += bufidx; bufidx = 0; } @@ -862,8 +887,8 @@ xfs_inumbers( } if (!error) { if (bufidx) { - if (copy_to_user(ubuffer, buffer, - bufidx * sizeof(*buffer))) + long written; + if (formatter(ubuffer, buffer, bufidx, &written)) error = XFS_ERROR(EFAULT); else *count += bufidx; --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_ioctl.c +++ linux-2.6/fs/xfs/linux-2.6/xfs_ioctl.c @@ -1019,7 +1019,7 @@ xfs_ioc_bulkstat( if (cmd == XFS_IOC_FSINUMBERS) error = xfs_inumbers(mp, &inlast, &count, - bulkreq.ubuffer); + bulkreq.ubuffer, xfs_inumbers_fmt); else if (cmd == XFS_IOC_FSBULKSTAT_SINGLE) error = xfs_bulkstat_single(mp, &inlast, bulkreq.ubuffer, &done); From owner-xfs@oss.sgi.com Mon Jul 2 08:26:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 08:26:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from ogre.sisk.pl (ogre.sisk.pl [217.79.144.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l62FQltL007800 for ; Mon, 2 Jul 2007 08:26:52 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id 146494FD71; Mon, 2 Jul 2007 16:42:12 +0200 (CEST) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13871-09; Mon, 2 Jul 2007 16:42:11 +0200 (CEST) Received: from [192.168.144.104] (iftwlan0.fuw.edu.pl [193.0.83.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id 6D7E34ADCB; Mon, 2 Jul 2007 16:42:11 +0200 (CEST) From: "Rafael J. Wysocki" To: David Greaves Subject: Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume Date: Mon, 2 Jul 2007 17:12:49 +0200 User-Agent: KMail/1.9.5 Cc: Tejun Heo , David Chinner , David Robinson , LVM general discussion and development , "'linux-kernel@vger.kernel.org'" , xfs@oss.sgi.com, linux-pm , LinuxRaid References: <46744065.6060605@dgreaves.com> <200707021608.56616.rjw@sisk.pl> <46890C7A.5040008@dgreaves.com> In-Reply-To: <46890C7A.5040008@dgreaves.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707021712.50323.rjw@sisk.pl> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux X-Virus-Status: Clean X-archive-position: 12067 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rjw@sisk.pl Precedence: bulk X-list: xfs Status: O Content-Length: 1291 Lines: 32 On Monday, 2 July 2007 16:32, David Greaves wrote: > Rafael J. Wysocki wrote: > > On Monday, 2 July 2007 12:56, Tejun Heo wrote: > >> David Greaves wrote: > >>>> Tejun Heo wrote: > >>>>> It's really weird tho. The PHY RDY status changed events are coming > >>>>> from the device which is NOT used while resuming > >>> There is an obvious problem there though Tejun (the errors even when sda > >>> isn't involved in the OS boot) - can I start another thread about that > >>> issue/bug later? I need to reshuffle partitions so I'd rather get the > >>> hibernate working first and then go back to it if that's OK? > >> Yeah, sure. The problem is that we don't know whether or how those two > >> are related. It would be great if there's a way to verify memory image > >> read from hibernation is intact. Rafael, any ideas? > > > > Well, s2disk has an option to compute an MD5 checksum of the image during > > the hibernation and verify it while reading the image. > (Assuming you mean the mainline version) > > Sounds like a good think to try next... > Couldn't see anything on this in ../Documentation/power/* > How do I enable it? Add 'compute checksum = y' to the s2disk's configuration file. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth From owner-xfs@oss.sgi.com Mon Jul 2 09:36:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 09:36:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_95 autolearn=no version=3.2.0-pre1-r499012 Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l62GaStL026038 for ; Mon, 2 Jul 2007 09:36:29 -0700 Received: from localhost (mailman.ukfsn.org [80.168.53.75]) by mail.ukfsn.org (Postfix) with ESMTP id 95885E705D; Mon, 2 Jul 2007 17:36:09 +0100 (BST) Received: from mail.ukfsn.org ([80.168.53.20]) by localhost (smtp-filter.ukfsn.org [80.168.53.75]) (amavisd-new, port 10024) with ESMTP id E6iypOde8rMW; Mon, 2 Jul 2007 17:35:06 +0100 (BST) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id E1145E6FC5; Mon, 2 Jul 2007 17:36:08 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1I5Ot1-0005H8-PD; Mon, 02 Jul 2007 17:36:27 +0100 Message-ID: <4689298B.2000407@dgreaves.com> Date: Mon, 02 Jul 2007 17:36:27 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070618) MIME-Version: 1.0 To: "Rafael J. Wysocki" Cc: Tejun Heo , David Chinner , David Robinson , LVM general discussion and development , "'linux-kernel@vger.kernel.org'" , xfs@oss.sgi.com, linux-pm , LinuxRaid Subject: Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume References: <46744065.6060605@dgreaves.com> <200707021608.56616.rjw@sisk.pl> <46890C7A.5040008@dgreaves.com> <200707021712.50323.rjw@sisk.pl> In-Reply-To: <200707021712.50323.rjw@sisk.pl> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12068 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Status: O Content-Length: 1726 Lines: 46 Rafael J. Wysocki wrote: > On Monday, 2 July 2007 16:32, David Greaves wrote: >> Rafael J. Wysocki wrote: >>> On Monday, 2 July 2007 12:56, Tejun Heo wrote: >>>> David Greaves wrote: >>>>>> Tejun Heo wrote: >>>>>>> It's really weird tho. The PHY RDY status changed events are coming >>>>>>> from the device which is NOT used while resuming >>>>> There is an obvious problem there though Tejun (the errors even when sda >>>>> isn't involved in the OS boot) - can I start another thread about that >>>>> issue/bug later? I need to reshuffle partitions so I'd rather get the >>>>> hibernate working first and then go back to it if that's OK? >>>> Yeah, sure. The problem is that we don't know whether or how those two >>>> are related. It would be great if there's a way to verify memory image >>>> read from hibernation is intact. Rafael, any ideas? >>> Well, s2disk has an option to compute an MD5 checksum of the image during >>> the hibernation and verify it while reading the image. >> (Assuming you mean the mainline version) >> >> Sounds like a good think to try next... >> Couldn't see anything on this in ../Documentation/power/* >> How do I enable it? > > Add 'compute checksum = y' to the s2disk's configuration file. Ah, right - that's uswsusp isn't it? Which isn't what I'm having problems with AFAIK? My suspend procedure is: xfs_freeze -f /scratch sync echo platform > /sys/power/disk echo disk > /sys/power/state xfs_freeze -u /scratch Which should work (actually it should work without the sync/xfs_freeze too). So to debug the problem I'd like to minimally extend this process rather than replace it with another approach. I take it there isn't an 'echo y > /sys/power/do_image_checksum'? David From owner-xfs@oss.sgi.com Mon Jul 2 12:43:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 12:43:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS, URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 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 l62JhBtL010973 for ; Mon, 2 Jul 2007 12:43:12 -0700 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 l62Jh4MI016397; Mon, 2 Jul 2007 15:43:04 -0400 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 l62Jh4ve007568; Mon, 2 Jul 2007 15:43:04 -0400 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 l62Jh2AD025731; Mon, 2 Jul 2007 15:43:03 -0400 Message-ID: <468954BD.50205@sandeen.net> Date: Mon, 02 Jul 2007 14:40:45 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Jesper Juhl CC: Linux Kernel Mailing List , David Chinner , xfs-masters@oss.sgi.com, xfs@oss.sgi.com, Andrew Morton Subject: Re: [PATCH][XFS][resend] memory leak; allocated transaction not freed in xfs_inactive_free_eofblocks() in failure case. References: <200707010116.54884.jesper.juhl@gmail.com> In-Reply-To: <200707010116.54884.jesper.juhl@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12069 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 Status: O Content-Length: 1304 Lines: 43 Jesper Juhl wrote: > (this is back from May 16 2007, resending since it doesn't look like > the patch ever made it in anywhere) > > Weird, looks like it's in cvs... http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.699&r2=text&tr2=1.698&f=h but not in git. -Eric > Fix XFS memory leak; allocated transaction not freed in xfs_inactive_free_eofblocks() in failure case. > > the code allocates a transaction, but in the case where 'truncate' is > !=0 and xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, 0); happens to return > an error, we'll just return from the function without dealing with the > memory allocated byxfs_trans_alloc() and assigned to 'tp', thus it'll be > orphaned/leaked - not good. > > Signed-off-by: Jesper Juhl > --- > fs/xfs/xfs_vnodeops.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/fs/xfs/xfs_vnodeops.c b/fs/xfs/xfs_vnodeops.c > index de17aed..32519cf 100644 > --- a/fs/xfs/xfs_vnodeops.c > +++ b/fs/xfs/xfs_vnodeops.c > @@ -1260,6 +1260,7 @@ xfs_inactive_free_eofblocks( > error = xfs_itruncate_start(ip, XFS_ITRUNC_DEFINITE, > ip->i_size); > if (error) { > + xfs_trans_cancel(tp, 0); > xfs_iunlock(ip, XFS_IOLOCK_EXCL); > return error; > } > > > From owner-xfs@oss.sgi.com Mon Jul 2 13:07:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 13:07:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_80,RCVD_IN_PSBL autolearn=no version=3.2.0-pre1-r499012 Received: from ogre.sisk.pl (ogre.sisk.pl [217.79.144.158]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l62K7qtL017143 for ; Mon, 2 Jul 2007 13:07:54 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by ogre.sisk.pl (Postfix) with ESMTP id 3EF774B5BA; Mon, 2 Jul 2007 21:44:36 +0200 (CEST) Received: from ogre.sisk.pl ([127.0.0.1]) by localhost (ogre.sisk.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15986-03; Mon, 2 Jul 2007 21:44:35 +0200 (CEST) Received: from [192.168.100.104] (nat-be2.aster.pl [212.76.37.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ogre.sisk.pl (Postfix) with ESMTP id 5F2DC53102; Mon, 2 Jul 2007 21:44:35 +0200 (CEST) From: "Rafael J. Wysocki" To: David Greaves Subject: Re: [linux-lvm] 2.6.22-rc5 XFS fails after hibernate/resume Date: Mon, 2 Jul 2007 22:15:11 +0200 User-Agent: KMail/1.9.5 Cc: Tejun Heo , David Chinner , David Robinson , LVM general discussion and development , "'linux-kernel@vger.kernel.org'" , xfs@oss.sgi.com, linux-pm , LinuxRaid References: <46744065.6060605@dgreaves.com> <200707021712.50323.rjw@sisk.pl> <4689298B.2000407@dgreaves.com> In-Reply-To: <4689298B.2000407@dgreaves.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707022215.12200.rjw@sisk.pl> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Scanned: amavisd-new at ogre.sisk.pl using MkS_Vir for Linux X-Virus-Status: Clean X-archive-position: 12070 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rjw@sisk.pl Precedence: bulk X-list: xfs Status: O Content-Length: 2100 Lines: 56 On Monday, 2 July 2007 18:36, David Greaves wrote: > Rafael J. Wysocki wrote: > > On Monday, 2 July 2007 16:32, David Greaves wrote: > >> Rafael J. Wysocki wrote: > >>> On Monday, 2 July 2007 12:56, Tejun Heo wrote: > >>>> David Greaves wrote: > >>>>>> Tejun Heo wrote: > >>>>>>> It's really weird tho. The PHY RDY status changed events are coming > >>>>>>> from the device which is NOT used while resuming > >>>>> There is an obvious problem there though Tejun (the errors even when sda > >>>>> isn't involved in the OS boot) - can I start another thread about that > >>>>> issue/bug later? I need to reshuffle partitions so I'd rather get the > >>>>> hibernate working first and then go back to it if that's OK? > >>>> Yeah, sure. The problem is that we don't know whether or how those two > >>>> are related. It would be great if there's a way to verify memory image > >>>> read from hibernation is intact. Rafael, any ideas? > >>> Well, s2disk has an option to compute an MD5 checksum of the image during > >>> the hibernation and verify it while reading the image. > >> (Assuming you mean the mainline version) > >> > >> Sounds like a good think to try next... > >> Couldn't see anything on this in ../Documentation/power/* > >> How do I enable it? > > > > Add 'compute checksum = y' to the s2disk's configuration file. > > Ah, right - that's uswsusp isn't it? Which isn't what I'm having problems with > AFAIK? > > My suspend procedure is: > > xfs_freeze -f /scratch > sync > echo platform > /sys/power/disk > echo disk > /sys/power/state > xfs_freeze -u /scratch > > Which should work (actually it should work without the sync/xfs_freeze too). > > So to debug the problem I'd like to minimally extend this process rather than > replace it with another approach. Well, this is not entirely "another approach". Only the saving of the image is done differently, the rest is the same. > I take it there isn't an 'echo y > /sys/power/do_image_checksum'? No, there is not anything like that. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth From owner-xfs@oss.sgi.com Mon Jul 2 17:01:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 17:01:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l6301itL013266 for ; Mon, 2 Jul 2007 17:01:45 -0700 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 l62NIZoJ026335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Jul 2007 17:18:35 -0600 Received: from rgmsgw02.us.oracle.com (rgmsgw02.us.oracle.com [138.1.186.52]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l62NIEge010216; Mon, 2 Jul 2007 17:18:14 -0600 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmsgw02.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l62NICIf015276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 17:18:13 -0600 Received: from mfasheh by ca-server1.us.oracle.com with local (Exim 4.63) (envelope-from ) id 1I5V9o-0004DV-HQ; Mon, 02 Jul 2007 16:18:12 -0700 Date: Mon, 2 Jul 2007 16:18:12 -0700 From: Mark Fasheh To: Christoph Hellwig Cc: Andrew Morton , Amit Arora , linux-fsdevel@vger.kernel.org, ocfs2-devel@oss.oracle.com, xfs@oss.sgi.com Subject: Re: [-mm PATCH] ocfs2: ->fallocate() support Message-ID: <20070702231812.GA15463@ca-server1.us.oracle.com> Reply-To: Mark Fasheh References: <20070621190143.GC17713@ca-server1.us.oracle.com> <20070630093413.GE22354@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070630093413.GE22354@infradead.org> Organization: Oracle Corporation User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Whitelist: TRUE X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12071 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mark.fasheh@oracle.com Precedence: bulk X-list: xfs Status: O Content-Length: 808 Lines: 24 On Sat, Jun 30, 2007 at 10:34:13AM +0100, Christoph Hellwig wrote: > Btw, it seems like ocfs implements the xfs preallocation ioctls. What > would people thing about moving those up to work over ->fallocate so they > can be used on all filesystems that support preallocation? That sounds like a good idea. We've already got a very good match on RESVP/UNRESVP with the various ->fallocate flags. I'm not sure whether we want to do this for ALLOCSP/FREESP - as far as I've heard those are hardly used. > While the ABI is quite ugly it has a huge userbase because it's the only > existing preallocation mechanism on Linux. Yeah, that was the primary reason I chose to implement the ioctl (along with the ->fallocate patch) --Mark -- Mark Fasheh Senior Software Developer, Oracle mark.fasheh@oracle.com From owner-xfs@oss.sgi.com Mon Jul 2 18:04:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 18:04:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l63140tL028956 for ; Mon, 2 Jul 2007 18:04:01 -0700 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 LAA21611; Tue, 3 Jul 2007 11:03:55 +1000 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 l6313reW9571117; Tue, 3 Jul 2007 11:03:54 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6313owx9496927; Tue, 3 Jul 2007 11:03:50 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 3 Jul 2007 11:03:50 +1000 From: David Chinner To: Michal Marek Cc: David Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [patch 3/3] Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode (try3) Message-ID: <20070703010349.GP989688@sgi.com> References: <20070619132549.266927601@suse.cz> <20070619132726.893544847@suse.cz> <20070628034957.GE989688@sgi.com> <4688C812.9020200@suse.cz> <20070702150509.GA32192@discovery.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070702150509.GA32192@discovery.suse.cz> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12072 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 Status: O Content-Length: 1073 Lines: 30 On Mon, Jul 02, 2007 at 05:05:09PM +0200, Michal Marek wrote: > On Mon, Jul 02, 2007 at 11:40:34AM +0200, Michal Marek wrote: > > David Chinner wrote: > > > I think we can remove xfs_bulkstat_one_compat() completely by using > > > the same method you used with the xfs_inumber_fmt functions. > > > > You mean xfs_ioc_bulkstat_compat() -> native xfs_bulkstat() -> native > > xfs_bulkstat_one() -> a compat output formatter, so a > > pointer-to-function passed to pointer-to-function? ;) I could (ab)use > > the void *private_data arg which xfs_bulkstat passes unmodified to the > > formatter; xfs_bulkstat_one() doesn't make use of it atm. I'll try it > > and post the result in a while. > > Hi David, what about this one? It about 30 lines shorter now :) Great. Added to my tree. I'll run some tests and then get it pushed out to the git trees. FWIW, I reordered the includes to match the order in most other XFS files so that it didn't break when I added other patches to the tree.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jul 2 18:10:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 18:10:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l631APtL030589 for ; Mon, 2 Jul 2007 18:10:27 -0700 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 LAA21856; Tue, 3 Jul 2007 11:10:23 +1000 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 l631ALeW9500595; Tue, 3 Jul 2007 11:10:22 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l631AJ7s9585873; Tue, 3 Jul 2007 11:10:19 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 3 Jul 2007 11:10:19 +1000 From: David Chinner To: lkml Cc: xfs-oss Subject: [PATCH] Teach do_mpage_readpage() about unwritten buffers Message-ID: <20070703011019.GQ989688@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12073 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 Status: O Content-Length: 2442 Lines: 60 Teach do_mpage_readpage() about unwritten extents so we can always map them in get_blocks rather than they are are holes on read. Allows setup_swap_extents() to use preallocated files on XFS filesystems for swap files without ever needing to convert them. Signed-Off-By: Dave Chinner --- fs/mpage.c | 5 +++-- fs/xfs/linux-2.6/xfs_aops.c | 13 +++---------- 2 files changed, 6 insertions(+), 12 deletions(-) Index: 2.6.x-xfs-new/fs/mpage.c =================================================================== --- 2.6.x-xfs-new.orig/fs/mpage.c 2007-05-29 16:17:59.000000000 +1000 +++ 2.6.x-xfs-new/fs/mpage.c 2007-06-27 22:39:35.568852270 +1000 @@ -207,7 +207,8 @@ do_mpage_readpage(struct bio *bio, struc * Map blocks using the result from the previous get_blocks call first. */ nblocks = map_bh->b_size >> blkbits; - if (buffer_mapped(map_bh) && block_in_file > *first_logical_block && + if (buffer_mapped(map_bh) && !buffer_unwritten(map_bh) && + block_in_file > *first_logical_block && block_in_file < (*first_logical_block + nblocks)) { unsigned map_offset = block_in_file - *first_logical_block; unsigned last = nblocks - map_offset; @@ -242,7 +243,7 @@ do_mpage_readpage(struct bio *bio, struc *first_logical_block = block_in_file; } - if (!buffer_mapped(map_bh)) { + if (!buffer_mapped(map_bh) || buffer_unwritten(map_bh)) { fully_mapped = 0; if (first_hole == blocks_per_page) first_hole = page_block; Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-06-05 22:14:39.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c 2007-06-27 22:39:29.545636749 +1000 @@ -1340,16 +1340,9 @@ __xfs_get_blocks( return 0; if (iomap.iomap_bn != IOMAP_DADDR_NULL) { - /* - * For unwritten extents do not report a disk address on - * the read case (treat as if we're reading into a hole). - */ - if (create || !(iomap.iomap_flags & IOMAP_UNWRITTEN)) { - xfs_map_buffer(bh_result, &iomap, offset, - inode->i_blkbits); - } - if (create && (iomap.iomap_flags & IOMAP_UNWRITTEN)) { - if (direct) + xfs_map_buffer(bh_result, &iomap, offset, inode->i_blkbits); + if (iomap.iomap_flags & IOMAP_UNWRITTEN) { + if (create && direct) bh_result->b_private = inode; set_buffer_unwritten(bh_result); } From owner-xfs@oss.sgi.com Mon Jul 2 20:28:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 20:28:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from smtp2.linux-foundation.org (smtp2.linux-foundation.org [207.189.120.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l633SXtL032629 for ; Mon, 2 Jul 2007 20:28:34 -0700 Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [207.189.120.55]) by smtp2.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with ESMTP id l633SXjt020958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jul 2007 20:28:34 -0700 Received: from box (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id l633SRx5028724; Mon, 2 Jul 2007 20:28:27 -0700 Date: Mon, 2 Jul 2007 20:28:27 -0700 From: Andrew Morton To: David Chinner Cc: lkml , xfs-oss , "linux-ext4@vger.kernel.org" Subject: Re: [PATCH] Teach do_mpage_readpage() about unwritten buffers Message-Id: <20070702202827.ffc59255.akpm@linux-foundation.org> In-Reply-To: <20070703011019.GQ989688@sgi.com> References: <20070703011019.GQ989688@sgi.com> X-Mailer: Sylpheed 2.4.1 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.181 $ X-Scanned-By: MIMEDefang 2.53 on 207.189.120.14 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12074 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: xfs Status: O Content-Length: 2832 Lines: 68 On Tue, 3 Jul 2007 11:10:19 +1000 David Chinner wrote: > Teach do_mpage_readpage() about unwritten extents so we can > always map them in get_blocks rather than they are are holes on > read. Allows setup_swap_extents() to use preallocated files on XFS > filesystems for swap files without ever needing to convert them. > > Signed-Off-By: Dave Chinner > > --- > fs/mpage.c | 5 +++-- > fs/xfs/linux-2.6/xfs_aops.c | 13 +++---------- > 2 files changed, 6 insertions(+), 12 deletions(-) > > Index: 2.6.x-xfs-new/fs/mpage.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/mpage.c 2007-05-29 16:17:59.000000000 +1000 > +++ 2.6.x-xfs-new/fs/mpage.c 2007-06-27 22:39:35.568852270 +1000 > @@ -207,7 +207,8 @@ do_mpage_readpage(struct bio *bio, struc > * Map blocks using the result from the previous get_blocks call first. > */ > nblocks = map_bh->b_size >> blkbits; > - if (buffer_mapped(map_bh) && block_in_file > *first_logical_block && > + if (buffer_mapped(map_bh) && !buffer_unwritten(map_bh) && > + block_in_file > *first_logical_block && > block_in_file < (*first_logical_block + nblocks)) { > unsigned map_offset = block_in_file - *first_logical_block; > unsigned last = nblocks - map_offset; > @@ -242,7 +243,7 @@ do_mpage_readpage(struct bio *bio, struc > *first_logical_block = block_in_file; > } > > - if (!buffer_mapped(map_bh)) { > + if (!buffer_mapped(map_bh) || buffer_unwritten(map_bh)) { > fully_mapped = 0; > if (first_hole == blocks_per_page) > first_hole = page_block; > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_aops.c 2007-06-05 22:14:39.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c 2007-06-27 22:39:29.545636749 +1000 > @@ -1340,16 +1340,9 @@ __xfs_get_blocks( > return 0; > > if (iomap.iomap_bn != IOMAP_DADDR_NULL) { > - /* > - * For unwritten extents do not report a disk address on > - * the read case (treat as if we're reading into a hole). > - */ > - if (create || !(iomap.iomap_flags & IOMAP_UNWRITTEN)) { > - xfs_map_buffer(bh_result, &iomap, offset, > - inode->i_blkbits); > - } > - if (create && (iomap.iomap_flags & IOMAP_UNWRITTEN)) { > - if (direct) > + xfs_map_buffer(bh_result, &iomap, offset, inode->i_blkbits); > + if (iomap.iomap_flags & IOMAP_UNWRITTEN) { > + if (create && direct) > bh_result->b_private = inode; > set_buffer_unwritten(bh_result); > } Seems sane, although one does wonder whether it's a worthy tradeoff. We add additional overhead to readpage[s]() just to avoid some IO during mkswap? Also, I wonder what ext4 does in this situation? From owner-xfs@oss.sgi.com Mon Jul 2 20:52:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jul 2007 20:52:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l633qYtL008387 for ; Mon, 2 Jul 2007 20:52:36 -0700 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 NAA25812; Tue, 3 Jul 2007 13:52:31 +1000 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 l633qTeW9478781; Tue, 3 Jul 2007 13:52:30 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l633qRjD9661878; Tue, 3 Jul 2007 13:52:27 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 3 Jul 2007 13:52:27 +1000 From: David Chinner To: Andrew Morton Cc: David Chinner , lkml , xfs-oss , "linux-ext4@vger.kernel.org" Subject: Re: [PATCH] Teach do_mpage_readpage() about unwritten buffers Message-ID: <20070703035227.GS989688@sgi.com> References: <20070703011019.GQ989688@sgi.com> <20070702202827.ffc59255.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070702202827.ffc59255.akpm@linux-foundation.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12075 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 Status: O Content-Length: 1300 Lines: 33 On Mon, Jul 02, 2007 at 08:28:27PM -0700, Andrew Morton wrote: > On Tue, 3 Jul 2007 11:10:19 +1000 David Chinner wrote: > > Seems sane, although one does wonder whether it's a worthy tradeoff. We > add additional overhead to readpage[s]() just to avoid some IO during > mkswap? It removes the hidden magic from XFS that hides unwritten extents behind holes so that they get zero filled by readpages. With other filesystems starting to use unwritten extents, these sorts of tricksy hacks should be avoided and we should be explicitly handling unwritten buffers just like we explicitly handle holes. The side effect of this change is that other things (like sys_swapon) behave sanely when faced with unwritten extents (i.e. they are not detected incorrectly as holes). FWIW, using unwritten extents for swap files means you can allocate gigabytes of swap space on demand, even under severe memory pressure because you don't need to write those gigabytes of data to disk. Also, the only way to read the contents of the swap file is to go directly to the underlying device so even if you screw up the permissions on the swap file it will still always read as zeros. So there are some benefits here.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jul 3 03:08:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jul 2007 03:08:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_80 autolearn=no version=3.2.0-pre1-r499012 Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l63A8rtL005713 for ; Tue, 3 Jul 2007 03:08:55 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id l63A3g77003667 for ; Tue, 3 Jul 2007 06:03:42 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l63A8s7x263866 for ; Tue, 3 Jul 2007 04:08:54 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l63A8rGY030281 for ; Tue, 3 Jul 2007 04:08:54 -0600 Received: from amitarora.in.ibm.com (amitarora.in.ibm.com [9.124.31.198]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l63A8qCs030185; Tue, 3 Jul 2007 04:08:53 -0600 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 2684618BDA3; Tue, 3 Jul 2007 15:39:08 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l63A8neG030402; Tue, 3 Jul 2007 15:38:49 +0530 Date: Tue, 3 Jul 2007 15:38:48 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: adilger@clusterfs.com, David Chinner , suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com, Christoph Hellwig Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070703100848.GA14936@amitarora.in.ibm.com> References: <20070614091458.GH5181@schatzie.adilger.int> <20070614120413.GD86004887@sgi.com> <20070614193347.GN5181@schatzie.adilger.int> <20070625132810.GA1951@amitarora.in.ibm.com> <20070625134500.GE1951@amitarora.in.ibm.com> <20070625150320.GA8686@amitarora.in.ibm.com> <20070625214626.GJ5181@schatzie.adilger.int> <20070626103247.GA19870@amitarora.in.ibm.com> <20070630102111.GB23568@infradead.org> <20070630165246.GA5159@schatzie.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070630165246.GA5159@schatzie.adilger.int> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12076 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aarora@linux.vnet.ibm.com Precedence: bulk X-list: xfs Status: O Content-Length: 1159 Lines: 28 On Sat, Jun 30, 2007 at 12:52:46PM -0400, Andreas Dilger wrote: > The @mode flags that are currently under consideration are (AFAIK): > > FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default allocate) */ > FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change size) */ > FA_FL_DEL_DATA 0x04 /* delete existing data in alloc range (default keep) */ We now have two sets of flags - 1) the above three with which I think no one has any issues with, and 2) the ones below, for which we need some discussions before finalizing on them. I will prefer fallocate going in mainline with the above three modes, and rest of the modes can be debated upon and discussed parallely. And, each new mode/flag can be pushed as a separate patch. This will not hold fallocate feature indefinitely... Please confirm if you find this approach ok. Otherwise, please object. Thanks! > FA_FL_ERR_FREE 0x08 /* free preallocation on error (default keep prealloc) */ > FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */ > FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */ -- Regards, Amit Arora From owner-xfs@oss.sgi.com Tue Jul 3 03:49:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jul 2007 03:49:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l63AnstL014866 for ; Tue, 3 Jul 2007 03:49:55 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1I5ff1-0007kf-If; Tue, 03 Jul 2007 11:31:07 +0100 Date: Tue, 3 Jul 2007 11:31:07 +0100 From: Christoph Hellwig To: "Amit K. Arora" Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, adilger@clusterfs.com, David Chinner , suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com, Christoph Hellwig Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070703103107.GA29763@infradead.org> Mail-Followup-To: Christoph Hellwig , "Amit K. Arora" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, adilger@clusterfs.com, David Chinner , suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com References: <20070614120413.GD86004887@sgi.com> <20070614193347.GN5181@schatzie.adilger.int> <20070625132810.GA1951@amitarora.in.ibm.com> <20070625134500.GE1951@amitarora.in.ibm.com> <20070625150320.GA8686@amitarora.in.ibm.com> <20070625214626.GJ5181@schatzie.adilger.int> <20070626103247.GA19870@amitarora.in.ibm.com> <20070630102111.GB23568@infradead.org> <20070630165246.GA5159@schatzie.adilger.int> <20070703100848.GA14936@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070703100848.GA14936@amitarora.in.ibm.com> User-Agent: Mutt/1.4.2.3i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12077 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 Status: O Content-Length: 1244 Lines: 26 On Tue, Jul 03, 2007 at 03:38:48PM +0530, Amit K. Arora wrote: > > FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default allocate) */ > > FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change size) */ > > FA_FL_DEL_DATA 0x04 /* delete existing data in alloc range (default keep) */ > > We now have two sets of flags - > 1) the above three with which I think no one has any issues with, and Yes, I do. FA_FL_DEL_DATA is plain stupid, a preallocation call should never delete data. FA_FL_DEALLOC should probably be a separate syscall because it's very different functionality. While we're at it I also dislike the FA_ prefix becuase it doesn't say anything and is far too generic. FALLOC_ is much better. > > FA_FL_ERR_FREE 0x08 /* free preallocation on error (default keep prealloc) */ NACK on this one. We should have just one behaviour, and from the thread that not freeing the allocation on error. > > FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */ > > FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */ NACK to these aswell. If i_size changes c/mtime need updates, if the size doesn't chamge they don't. No need to add more flags for this. From owner-xfs@oss.sgi.com Tue Jul 3 04:46:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jul 2007 04:46:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AWL,BAYES_60 autolearn=no version=3.2.0-pre1-r499012 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l63BkmtL001992 for ; Tue, 3 Jul 2007 04:46:49 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l63Bkmiw019193 for ; Tue, 3 Jul 2007 07:46:48 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l63BkkRQ240090 for ; Tue, 3 Jul 2007 05:46:48 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l63Bkk7j005778 for ; Tue, 3 Jul 2007 05:46:46 -0600 Received: from amitarora.in.ibm.com (amitarora.in.ibm.com [9.124.31.198]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l63BkioM005723; Tue, 3 Jul 2007 05:46:45 -0600 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 65C9618BDA3; Tue, 3 Jul 2007 17:16:56 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l63BktDn006218; Tue, 3 Jul 2007 17:16:55 +0530 Date: Tue, 3 Jul 2007 17:16:50 +0530 From: "Amit K. Arora" To: Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, adilger@clusterfs.com, David Chinner , suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070703114650.GB14936@amitarora.in.ibm.com> References: <20070614193347.GN5181@schatzie.adilger.int> <20070625132810.GA1951@amitarora.in.ibm.com> <20070625134500.GE1951@amitarora.in.ibm.com> <20070625150320.GA8686@amitarora.in.ibm.com> <20070625214626.GJ5181@schatzie.adilger.int> <20070626103247.GA19870@amitarora.in.ibm.com> <20070630102111.GB23568@infradead.org> <20070630165246.GA5159@schatzie.adilger.int> <20070703100848.GA14936@amitarora.in.ibm.com> <20070703103107.GA29763@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070703103107.GA29763@infradead.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12079 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aarora@linux.vnet.ibm.com Precedence: bulk X-list: xfs Status: O Content-Length: 2736 Lines: 62 On Tue, Jul 03, 2007 at 11:31:07AM +0100, Christoph Hellwig wrote: > On Tue, Jul 03, 2007 at 03:38:48PM +0530, Amit K. Arora wrote: > > > FA_FL_DEALLOC 0x01 /* deallocate unwritten extent (default allocate) */ > > > FA_FL_KEEP_SIZE 0x02 /* keep size for EOF {pre,de}alloc (default change size) */ > > > FA_FL_DEL_DATA 0x04 /* delete existing data in alloc range (default keep) */ > > > > We now have two sets of flags - > > 1) the above three with which I think no one has any issues with, and > > Yes, I do. FA_FL_DEL_DATA is plain stupid, a preallocation call should > never delete data. FA_FL_DEALLOC should probably be a separate syscall > because it's very different functionality. Well, if you see the modes proposed using above flags : #define FA_ALLOCATE 0 #define FA_DEALLOCATE FA_FL_DEALLOC #define FA_RESV_SPACE FA_FL_KEEP_SIZE #define FA_UNRESV_SPACE (FA_FL_DEALLOC | FA_FL_KEEP_SIZE | FA_FL_DEL_DATA) FA_FL_DEL_DATA is _not_ being used for preallocation. We have two modes for preallocation FA_ALLOCATE and FA_RESV_SPACE, which do not use this flag. Hence prealloction will never delete data. This mode is required only for FA_UNRESV_SPACE, which is a deallocation mode, to support any existing XFS aware applications/usage-scenarios. And, regarding FA_FL_DEALLOC being a separate syscall - I think then the very purpose of @mode argument is not justified. We have this mode so that we can provide more features like this. That said, I don't say that we should make things very complicated; but, atleast we should provide some basic features which we expect most of the applications wanting preallocation to use. To start with, we need to cater to already existing applications/user base who use XFS preallocation feature. And further advanced features, like goal based preallocation, can be implemented as a separate syscall. > While we're at it I also dislike the FA_ prefix becuase it doesn't say > anything and is far too generic. FALLOC_ is much better. Ok. This can be changed in the next take. > > > FA_FL_ERR_FREE 0x08 /* free preallocation on error (default keep prealloc) */ > > NACK on this one. We should have just one behaviour, and from the thread > that not freeing the allocation on error. I agree on this one. > > > FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */ > > > FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */ > > NACK to these aswell. If i_size changes c/mtime need updates, if the size > doesn't chamge they don't. No need to add more flags for this. This requirement was from the point of view of HSM applications. Hope you saw Andreas previous post and are keeping that in mind. -- Regards, Amit Arora From owner-xfs@oss.sgi.com Tue Jul 3 04:45:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jul 2007 04:45:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from santro.websitewelcome.com (wiredroads.net [74.53.104.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l63BjctL001566 for ; Tue, 3 Jul 2007 04:45:39 -0700 Received: from emg707 by santro.websitewelcome.com with local (Exim 4.63) (envelope-from ) id 1I5Zrh-0005jA-N2; Mon, 02 Jul 2007 23:19:49 -0500 Received: from 41.220.75.3 ([41.220.75.3]) (SquirrelMail authenticated user team1@easymarketinggroup.com) by easymarketinggroup.com with HTTP; Mon, 2 Jul 2007 23:19:49 -0500 (CDT) Message-ID: <54231.41.220.75.3.1183436389.squirrel@easymarketinggroup.com> Date: Mon, 2 Jul 2007 23:19:49 -0500 (CDT) Subject: Congratulation On Your Winnis From: "Richard K Lloyds" Reply-To: agentsharon_cole007@yahoo.co.uk User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - santro.websitewelcome.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [32364 32366] / [47 12] X-AntiAbuse: Sender Address Domain - yahoo.co.uk X-Source: X-Source-Args: X-Source-Dir: To: undisclosed-recipients:; X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12078 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: britishlottery207@yahoo.co.uk Precedence: bulk X-list: xfs Status: O Content-Length: 597 Lines: 23 The National Lottery 3b Olympic Way Sefton Business Park Aintree LiverpoolL30 1RD UNITED KINGDOM (Customer Services) This email is to inform you that you emerged a winner of £552,000 on our online draws which was played on the 29th of June,2007. For further information about your winnings,contact our Lottery Fiduciary agent with the following contact address. Name; Mrs.Sharon Cole E-mail Address:-agentsharon_cole007@yahoo.co.uk Phone +447045721308 Congratulations once more from all members and staff of this program. Yours Truly, Richard K Lloyds Co-ordinator(Online Promo Programmes) From owner-xfs@oss.sgi.com Tue Jul 3 09:44:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jul 2007 09:44:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l63GibtL014423; Tue, 3 Jul 2007 09:44:39 -0700 X-SBRS: None X-RemoteIP: 212.74.100.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkchABoXikbUSmSR/2dsb2JhbACGG4gS Received: from [83.180.63.68] by mail-5.uk.tiscali.com with HTTP; Tue, 3 Jul 2007 18:34:31 +0200 Date: Tue, 3 Jul 2007 09:34:31 -0700 Message-ID: <46414F72000046C2@mail-5-uk.mail.tiscali.sys> From: vanyolanda@handbag.com Subject: Award Program Batch Number EU75011. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12080 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vanyolanda@handbag.com Precedence: bulk X-list: xfs Status: O Content-Length: 756 Lines: 26 Award Program Batch Number EU75011. This is to inform you that your Email Address attached to a Ticket Number (1O6012) has won the prize Sum of: 950,000.00 (Nine Hundred and Fifty Thousand Euro), in an Email Sweepstakes program held on the 3rd of July 2007. Do contact the Details below for your claim: Contact Person: Mr. Peter Smith Tel:+31-624-595-853 Email:( luckydayclaimnl@aim.com ) WINNING INFORMATIONS: Reference Number (4226119), Serial Number 176087, Lucky Numbers: 12,42,67,65, Batch Number EU75011 Congratulations! SINCERLY YOURS, Mrs. Mariam Dominquez. PROMOTION CO-ORDINATOR. ___________________________________________________________ Tiscali Broadband from 14.99 with free setup! http://www.tiscali.co.uk/products/broadband/ From owner-xfs@oss.sgi.com Tue Jul 3 22:37:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jul 2007 22:37:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 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 l645bStL032491 for ; Tue, 3 Jul 2007 22:37:30 -0700 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 PAA07306; Wed, 4 Jul 2007 15:37:02 +1000 Message-ID: <468B31FD.2020703@sgi.com> Date: Wed, 04 Jul 2007 15:37:01 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: "Amit K. Arora" CC: Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, adilger@clusterfs.com, David Chinner , suparna@in.ibm.com, cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate References: <20070614193347.GN5181@schatzie.adilger.int> <20070625132810.GA1951@amitarora.in.ibm.com> <20070625134500.GE1951@amitarora.in.ibm.com> <20070625150320.GA8686@amitarora.in.ibm.com> <20070625214626.GJ5181@schatzie.adilger.int> <20070626103247.GA19870@amitarora.in.ibm.com> <20070630102111.GB23568@infradead.org> <20070630165246.GA5159@schatzie.adilger.int> <20070703100848.GA14936@amitarora.in.ibm.com> <20070703103107.GA29763@infradead.org> <20070703114650.GB14936@amitarora.in.ibm.com> In-Reply-To: <20070703114650.GB14936@amitarora.in.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12081 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 Status: O Content-Length: 957 Lines: 21 Amit K. Arora wrote: >>>> FA_FL_NO_MTIME 0x10 /* keep same mtime (default change on size, data change) */ >>>> FA_FL_NO_CTIME 0x20 /* keep same ctime (default change on size, data change) */ >> NACK to these aswell. If i_size changes c/mtime need updates, if the size >> doesn't chamge they don't. No need to add more flags for this. > > This requirement was from the point of view of HSM applications. Hope > you saw Andreas previous post and are keeping that in mind. > We use this capability in XFS at the moment. I think this is mainly for DMF (HSM) but is done via the xfs handle interface (xfs_open_by_handle) AFAICT. This sets up a set of invisible operations (xfs_invis_file_operations). xfs_file_ioctl_invis goes on to set IO_INVIS which goes on to set ATTR_DMI which is then tested in xfs_change_file_space() (which handles XFS_IOC_RESVSP & friends) for whether xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG) is called or not. --Tim From owner-xfs@oss.sgi.com Wed Jul 4 14:00:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jul 2007 14:00:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=5.0 tests=BAYES_99,J_CHICKENPOX_53, J_CHICKENPOX_64,J_CHICKENPOX_72 autolearn=no version=3.2.0-pre1-r499012 Received: from bravo657.server4you.de (bravo657.server4you.de [85.25.132.118]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l64L0VtL009684 for ; Wed, 4 Jul 2007 14:00:33 -0700 Received: by bravo657.server4you.de (Postfix, from userid 30) id 3B92722B509; Wed, 4 Jul 2007 22:36:27 +0200 (CEST) To: xfs@oss.sgi.com Subject: Online Easy Job !!! From: Chong Hu Corporation Reply-To: chun_hu16@yahoo.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20070704203627.3B92722B509@bravo657.server4you.de> Date: Wed, 4 Jul 2007 22:36:27 +0200 (CEST) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12082 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: employment@chonghucorp.com Precedence: bulk X-list: xfs Status: O Content-Length: 3098 Lines: 73 Payment Managers Wanted for 2007 Quarter Chong Hu Corporation Tel:+81-(50)5532-5187 Employment Opportunity for the 2007 Quarter. We are an International trading company with our corporate headquarters based in Japan.Since establishment in 1974 we have done our business in Mainland Asia and Oceania,in 1990 we extended our Region of supplies due to continious demands to Northern America and Europe.We deal on raw factory materials and finished personal care products including live long products.Due to our competent records fortreating customer demands and supplies,customers have refered us to other possible clients and we have been recieving orders from Northern America, Europe,Australia and other part of the world. There have been difficulties when Selling to the United States due to their mode of payment, they often pay with Money Orders and checks that can only be cashed in United States only it takes about 3 months for payment to clear in Japan. We need Responsible, Legitimate and Trustworthy Persons in the U.S to work as FINANCE CO-ORDINATORS to assist us in processing the Payments from our Customers and we offer a very attractive Remuneration package and good carrier prospects. JOB DETAILS: 1. Upon verification of your application and found satisfactory,yourcontact details shall be given to our Clients in your vicinity in respect of their further payment. 2. Contact us as soon as payment is received by you.An instruction shall be given to you further on how to get the funds to our company. 3. Your Remuneration shall be 10% of each payment received. 4. A good customer relationship is expected from you. These are Legitimate Transactions between our Customers and our Company Representatives over the years and there is no legal risk as these are Payments for Goods already bought and delivered.Upon good conduct you are eligible to be a permanent staff of The Craft Centre & Design Gallery. If you meet these conditions and wish to apply send this reference position number #3456234 and please contact our recruiting manager through this e-mail address( chun_hu16@yahoo.com ) to receive a Representative Contract agreement. Prospective finance co-ordinators should forward the following info: 1.Full names 2.Phone number/fax 3.Full contact address ( p.o.box not allowed ) 4.Marital status and Age 5.Nationality: 6.Sex ANYONE BELOW 21 YEARS OF AGE IS NOT ELIGIBLE FOR THIS OFFER. Contact Person:Chun Hu E-mail: chun_hu16@yahoo.com Time: 24 Hours daily by e-mail Human Relations Officer. Hayley Walker - Director Jane Needham - Manager Franklin Wash- Human Relations Officer Laura Bairstow - Jewllery Co-ordinator Samantha Bryan - Exhibitions & Educational Co-ordinator Lesley Barrett - Hand-Made Card Selector Janet Chin - Gallery Assistant Thanks for taking time to read our offer. My Regards, Chun Hu Chong Hu Corporation.( REFERRING AGENT)for Xin Laou (II) Copyright Reserved 2007 NOTE : ANY FORM OF IRREGULARITY OR FRAUDULENT ACT WOULD NOT BE CONDOLED. From owner-xfs@oss.sgi.com Thu Jul 5 17:02:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jul 2007 17:02:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 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 l6602itL012755 for ; Thu, 5 Jul 2007 17:02:46 -0700 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 JAA03131; Fri, 6 Jul 2007 09:43:48 +1000 Message-ID: <468D82BA.3020901@sgi.com> Date: Fri, 06 Jul 2007 09:46:02 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: linux-xfs@oss.sgi.com Subject: TAKE 960527 - DMAPI dm_punch_hole and dm_probe hole have several problems Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12083 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 Status: O Content-Length: 573 Lines: 16 Date: Fri Jul 6 09:39:04 AEST 2007 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29084a fs/xfs/dmapi/xfs_dm.c - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h - pv 960527, rv dgc - Implement variable size DMAPI probe/punch hole. We don't strictly follow the DMAPI spec, see the comments in the code for more details. From owner-xfs@oss.sgi.com Fri Jul 6 14:10:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 06 Jul 2007 14:10:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from lsv.uky.edu (lsv.uky.edu [128.163.184.152]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l66LAqtL004008 for ; Fri, 6 Jul 2007 14:10:54 -0700 Received: from lsv (lsv.uky.edu) by lsv.uky.edu (LSMTP for Windows NT v1.1b) with SMTP id <0.01BA993C@lsv.uky.edu>; Fri, 6 Jul 2007 17:00:52 -0400 Date: Fri, 6 Jul 2007 17:00:52 -0400 From: "University of Kentucky LISTSERV Server (14.4)" Subject: Message ("Your message dated Fri, 6 Jul 2007 15:50:37 -0500...") To: linux-xfs@oss.sgi.com Message-ID: X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12084 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: LISTSERV@LSV.UKY.EDU Precedence: bulk X-list: xfs Status: O Content-Length: 169 Lines: 4 Your message dated Fri, 6 Jul 2007 15:50:37 -0500 with subject "Returned mail: see transcript for details" has been successfully distributed to the AANDSALUMNI list. From owner-xfs@oss.sgi.com Sun Jul 8 12:11:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 12:11:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=5.0 tests=BAYES_99,J_CHICKENPOX_34, SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 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 l68JBPtL002898 for ; Sun, 8 Jul 2007 12:11:27 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1I7bRO-0007OL-P4 for linux-xfs@oss.sgi.com; Sun, 08 Jul 2007 20:25:02 +0200 Received: from cm169-230.liwest.at ([81.10.169.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Jul 2007 20:25:02 +0200 Received: from jp by cm169-230.liwest.at with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Jul 2007 20:25:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Jakob Praher Subject: usage pattern: xfsrestore to mirror disks Date: Sun, 08 Jul 2007 20:18:18 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cm169-230.liwest.at User-Agent: Thunderbird 2.0.0.4 (X11/20070618) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12085 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jp@hapra.at Precedence: bulk X-list: xfs Status: O Content-Length: 707 Lines: 22 hi all, first of all: I am a very happy user of xfs for a long time now. I use xfs in tandem with lvm2 and I have to say I am very pleased. Now a question: There are two modes of using xfs(dump,restore): non-cumulative and cumulative. Is this cumulative mode also good to work with full dumps (level0). E.g. the data I have to mirror is not large, and I don't want to rely on inventory data. So I want for instance if between two full dumps a file F was deleted, it should get deleted when I do xfsrestore for the second time. I don't keep the xfsdump output files but i just apply them via ssh. So something like that would be great! Maybe someone can shed some light on that. thanks --Jakob From owner-xfs@oss.sgi.com Sun Jul 8 22:09:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 22:09:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 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 l6959FtL013881 for ; Sun, 8 Jul 2007 22:09:17 -0700 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 PAA01667; Mon, 9 Jul 2007 15:09:12 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 53EE758C38F1; Mon, 9 Jul 2007 15:09:12 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 964469 - XFS Concurrent Multi-File Data Streams Message-Id: <20070709050912.53EE758C38F1@chook.melbourne.sgi.com> Date: Mon, 9 Jul 2007 15:09:12 +1000 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12086 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 Status: O Content-Length: 6487 Lines: 138 Concurrent Multi-File Data Streams In media spaces, video is often stored in a frame-per-file format. When dealing with uncompressed realtime HD video streams in this format, it is crucial that files do not get fragmented and that multiple files a placed contiguously on disk. When multiple streams are being ingested and played out at the same time, it is critical that the filesystem does not cross the streams and interleave them together as this creates seek and readahead cache miss latency and prevents both ingest and playout from meeting frame rate targets. This patch set creates a "stream of files" concept into the allocator to place all the data from a single stream contiguously on disk so that RAID array readahead can be used effectively. Each additional stream gets placed in different allocation groups within the filesystem, thereby ensuring that we don't cross any streams. When an AG fills up, we select a new AG for the stream that is not in use. The core of the functionality is the stream tracking - each inode that we create in a directory needs to be associated with the directories' stream. Hence every time we create a file, we look up the directories' stream object and associate the new file with that object. Once we have a stream object for a file, we use the AG that the stream object point to for allocations. If we can't allocate in that AG (e.g. it is full) we move the entire stream to another AG. Other inodes in the same stream are moved to the new AG on their next allocation (i.e. lazy update). Stream objects are kept in a cache and hold a reference on the inode. Hence the inode cannot be reclaimed while there is an outstanding stream reference. This means that on unlink we need to remove the stream association and we also need to flush all the associations on certain events that want to reclaim all unreferenced inodes (e.g. filesystem freeze). Date: Mon Jul 9 15:08:16 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes@sgi.com,hch@lst.de,donaldd@sgi.com,bnaujok@sgi.com,vapo@sgi.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:29096a fs/xfs/xfs_filestream.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_filestream.h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_mru_cache.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mru_cache.h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_mru_cache.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mru_cache.c - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_filestream.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_filestream.c - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfsidbg.c - 1.316 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.316&r2=text&tr2=1.315&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_ag.h - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ag.h.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs.h - 1.49 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_vnodeops.c - 1.702 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.702&r2=text&tr2=1.701&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_fs.h - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_vfsops.c - 1.522 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.522&r2=text&tr2=1.521&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_clnt.h - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_clnt.h.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_mount.h - 1.237 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.237&r2=text&tr2=1.236&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_inode.c - 1.465 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.465&r2=text&tr2=1.464&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_inode.h - 1.222 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.222&r2=text&tr2=1.221&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_fsops.c - 1.127 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_bmap.c - 1.371 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.371&r2=text&tr2=1.370&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/xfs_dinode.h - 1.81 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dinode.h.diff?r1=text&tr1=1.81&r2=text&tr2=1.80&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/Makefile-linux-2.6 - 1.207 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.207&r2=text&tr2=1.206&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/linux-2.6/xfs_globals.c - 1.70 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_globals.c.diff?r1=text&tr1=1.70&r2=text&tr2=1.69&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/linux-2.6/xfs_linux.h - 1.154 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.154&r2=text&tr2=1.153&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/linux-2.6/xfs_sysctl.c - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.c.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h - Concurrent Multi-File Data Streams feature check in. fs/xfs/linux-2.6/xfs_sysctl.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h - Concurrent Multi-File Data Streams feature check in. From owner-xfs@oss.sgi.com Sun Jul 8 22:13:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 22:13:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.2.0-pre1-r499012 (2007-01-23) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_50,URIBL_RHS_ABUSE autolearn=no version=3.2.0-pre1-r499012 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com