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 [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id l695DDtL015366 for ; Sun, 8 Jul 2007 22:13:15 -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 PAA01727; Mon, 9 Jul 2007 15:13:11 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 44DE058C38F1; Mon, 9 Jul 2007 15:13:11 +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: <20070709051311.44DE058C38F1@chook.melbourne.sgi.com> Date: Mon, 9 Jul 2007 15:13:11 +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: 12087 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: 500 Lines: 16 Export radix_tree_preload() Date: Mon Jul 9 15:11:56 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:29097a lib/radix-tree.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/lib/radix-tree.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - Export radix_tree_preload() so it is available to modules. From owner-xfs@oss.sgi.com Sun Jul 8 22:17:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 22:17: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.6 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_34 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 l695HptL017022 for ; Sun, 8 Jul 2007 22:17:52 -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 PAA01602; Mon, 9 Jul 2007 15:03:54 +1000 Message-ID: <4691C1BA.4040603@sgi.com> Date: Mon, 09 Jul 2007 15:03:54 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Jakob Praher CC: linux-xfs@oss.sgi.com Subject: Re: usage pattern: xfsrestore to mirror disks References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------000502090405050300030608" X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12088 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: 3194 Lines: 89 This is a multi-part message in MIME format. --------------000502090405050300030608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jakob, Jakob Praher wrote: > 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. > The cumulative mode really only relates to restore and not xfsdump. xfsrestore in cumulative mode keeps its version of the directory tree around (restoredir/xfsrestorehousekeepingdir/tree) so that it can use it to compare with and decide if directory entries have been renamed, deleted etc.. The code has been written to do this given an initial level 0 dump and then delta dumps (incremental or resumed). If you try to use a 2nd level 0 dump on restore then it will fail to work - it won't restore anything. It fails in xfsdump/restore/content.c/dumpcompat() when it compares the restores uuid from persp->a.lastdumpid with the incremental's uuid stored in scrhdrp->cih_last_id (and for a full dump the cih_last_id won't be set). Unfortunatly, a flag is set in restore so that it stops it from reporting this error (not sure why). I tried circumventing this uuid check (see the patch) and things seemed to work ok (it did the renames and deletes). However, I'm uncertain of any other repercussions - it's been a while since I looked at cumulative restores. Maybe others might know. I wonder if other tools might be useful to you... xfscopy,...? --Tim --------------000502090405050300030608 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="restore_hack.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="restore_hack.patch" =========================================================================== Index: xfsdump/restore/content.c =========================================================================== --- a/xfsdump/restore/content.c 2007-07-09 14:41:15.000000000 +1000 +++ b/xfsdump/restore/content.c 2007-07-09 14:36:54.000000000 +1000 @@ -2019,7 +2019,7 @@ content_stream_restore( ix_t thrdix ) } else if ( dumpcompat( resumepr, level, *baseidp, - BOOL_FALSE )) { + BOOL_TRUE )) { if ( uuid_compare( lastdumprejectedid, grhdrp->gh_dumpid) == 0) { matchpr = BOOL_FALSE; @@ -6762,7 +6762,7 @@ dumpcompat( bool_t resumepr, ix_t level, "selected dump not based on " "previously applied dump\n")); } - return BOOL_FALSE; + /*return BOOL_FALSE;*/ return BOOL_TRUE; } } } --------------000502090405050300030608-- From owner-xfs@oss.sgi.com Sun Jul 8 22:21:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 22:21:16 -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 l695LBtL018231 for ; Sun, 8 Jul 2007 22:21:13 -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 PAA01962; Mon, 9 Jul 2007 15:21:09 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id DD76158C38F1; Mon, 9 Jul 2007 15:21:08 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 964469 - XFS Concurrent Multi-File Data Streams Message-Id: <20070709052108.DD76158C38F1@chook.melbourne.sgi.com> Date: Mon, 9 Jul 2007 15:21:08 +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: 12089 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: 1162 Lines: 29 Quota inode has no parent. Avoid using a special "zero inode" as the parent of the quota inode as this can confuse the filestreams code into thinking the quota inode has a parent. We do not want the quota inode to follow filestreams allocation rules, so pass a NULL as the parent inode and detect this condition when doing stream associations. Date: Mon Jul 9 15:20:37 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes@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:29098a fs/xfs/xfs_inode.c - 1.466 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.466&r2=text&tr2=1.465&f=h - Check for inodes without parents and don't try to associate them or inherit from a non-existent parent inode. fs/xfs/quota/xfs_qm.c - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h - Do not use a special zero inode as the quota inode parent. This avoids incorrect detection of a parent inode when allocating new inodes. From owner-xfs@oss.sgi.com Sun Jul 8 22:44:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 22:44: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=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 l695i6tL023415 for ; Sun, 8 Jul 2007 22:44:08 -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 PAA02456; Mon, 9 Jul 2007 15:44:02 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 8FD1558C38F1; Mon, 9 Jul 2007 15:44:02 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 967353 - cleanup function name handling for debug code Message-Id: <20070709054402.8FD1558C38F1@chook.melbourne.sgi.com> Date: Mon, 9 Jul 2007 15:44:02 +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: 12090 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: 1531 Lines: 39 Clean up function name handling in tracing code Remove the hardcoded "fnames" for tracing, and just embed them in tracing macros via __FUNCTION__. Kills a lot of #ifdefs too. Signed-Off-By: Eric Sandeen Date: Mon Jul 9 15:43:22 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29099a fs/xfs/xfs_bmap_btree.c - 1.161 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.161&r2=text&tr2=1.160&f=h - Use __FUNCTION__ rather than hardcoded fnames for tracing. fs/xfs/xfs_inode.c - 1.467 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.467&r2=text&tr2=1.466&f=h - Use __FUNCTION__ rather than hardcoded fnames for tracing. fs/xfs/xfs_alloc.c - 1.187 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.187&r2=text&tr2=1.186&f=h - Use __FUNCTION__ rather than hardcoded fnames for tracing. fs/xfs/xfs_bmap.h - 1.99 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.99&r2=text&tr2=1.98&f=h - Use __FUNCTION__ rather than hardcoded fnames for tracing. fs/xfs/xfs_bmap.c - 1.372 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.372&r2=text&tr2=1.371&f=h - Use __FUNCTION__ rather than hardcoded fnames for tracing. From owner-xfs@oss.sgi.com Sun Jul 8 22:56:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 22:56: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.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 l695u6tL026226 for ; Sun, 8 Jul 2007 22:56:08 -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 PAA02756; Mon, 9 Jul 2007 15:56:04 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 5D33C58C38F1; Mon, 9 Jul 2007 15:56:04 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 967354 - new compat ioctl handlers Message-Id: <20070709055604.5D33C58C38F1@chook.melbourne.sgi.com> Date: Mon, 9 Jul 2007 15:56:04 +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: 12091 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: 672 Lines: 21 Compat ioctl handler for XFS_IOC_FSGEOMETRY_V1. i386 struct xfs_fsop_geom_v1 has no padding after the last member, so the size is different. Signed-Off-By: Michal Marek Date: Mon Jul 9 15:55:14 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: mmarek@suse.cz The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29100a fs/xfs/linux-2.6/xfs_ioctl32.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h - Compat ioctl handler for XFS_IOC_FSGEOMETRY_V1. From owner-xfs@oss.sgi.com Sun Jul 8 23:01:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 23:01:20 -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 l6961CtL029631 for ; Sun, 8 Jul 2007 23:01:16 -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 QAA02960; Mon, 9 Jul 2007 16:01:10 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 1938C58C38F1; Mon, 9 Jul 2007 16:01:10 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 967354 - new compat ioctl handlers Message-Id: <20070709060110.1938C58C38F1@chook.melbourne.sgi.com> Date: Mon, 9 Jul 2007 16:01:10 +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: 12092 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: 737 Lines: 22 Compat ioctl handler for handle operations 32bit struct xfs_fsop_handlereq has different size and offsets (due to pointers). TODO: case XFS_IOC_{FSSETDM,ATTRLIST,ATTRMULTI}_BY_HANDLE still not handled. Signed-Off-By: Michal Marek Date: Mon Jul 9 16:00:29 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: mmarek@suse.cz The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29101a fs/xfs/linux-2.6/xfs_ioctl32.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - Compat ioctl handlers for several by-handle ioctls. From owner-xfs@oss.sgi.com Sun Jul 8 23:05:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jul 2007 23:05:43 -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 l6965ctL030975 for ; Sun, 8 Jul 2007 23:05:40 -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 QAA03049; Mon, 9 Jul 2007 16:05:37 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id EAC6358C38F1; Mon, 9 Jul 2007 16:05:36 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 967354 - new compat ioctl handlers Message-Id: <20070709060536.EAC6358C38F1@chook.melbourne.sgi.com> Date: Mon, 9 Jul 2007 16:05:36 +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: 12093 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: 1939 Lines: 42 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 formatter" 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 formatter" mecanism to xfs_inumbers(). Signed-Off-By: Michal Marek Date: Mon Jul 9 16:05:13 AEST 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: mmarek@suse.cz The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:29102a fs/xfs/xfs_itable.c - 1.152 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.152&r2=text&tr2=1.151&f=h - Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode fs/xfs/xfs_itable.h - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h - Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode fs/xfs/linux-2.6/xfs_ioctl.c - 1.145 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.145&r2=text&tr2=1.144&f=h - Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode fs/xfs/linux-2.6/xfs_ioctl32.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl32.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - Fix XFS_IOC_FSBULKSTAT{,_SINGLE} and XFS_IOC_FSINUMBERS in compat mode From owner-xfs@oss.sgi.com Mon Jul 9 00:38:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jul 2007 00:38: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=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 l697cUtL029196 for ; Mon, 9 Jul 2007 00:38:32 -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 RAA04955; Mon, 9 Jul 2007 17:38:28 +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 l697cReW17092704; Mon, 9 Jul 2007 17:38:28 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l697cQ1U15924393; Mon, 9 Jul 2007 17:38:26 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 9 Jul 2007 17:38:26 +1000 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: Review: fix truncate vs null files issues Message-ID: <20070709073826.GO31489@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: 12094 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: 2269 Lines: 67 When we change the file size via xfs_setattr(), we log the new, in-memory file size in the transaction. We do this without having flushed any dirty data so if we have previously extended the file we change the on disk file size without having written the data first. This is a problem for both growing the file and truncating the file. The truncate case is partially hidden by the VTRUNCATE code, but if the file has not been closed before a crash has occurred we can still get NULLs appearing in files. The following patch fixes this problem by flushing the range between the on-disk filesize and the new file size as long as the new file size is larger than the on disk file size. Comments? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_vnodeops.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vnodeops.c 2007-06-20 17:59:35.050768978 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c 2007-06-21 15:18:17.187347809 +1000 @@ -595,7 +595,30 @@ xfs_setattr( code = xfs_igrow_start(ip, vap->va_size, credp); } xfs_iunlock(ip, XFS_ILOCK_EXCL); - vn_iowait(vp); /* wait for the completion of any pending DIOs */ + + /* + * We are going to log the inode size change in this + * transaction so any previous writes that are beyond the on + * disk EOF and the new EOF that have not been written out need + * to be written here. If we do not write the data out, we + * expose ourselves to the null files problem. + * + * Only flush from the on disk size to the smaller of the in + * memory file size or the new size as that's the range we + * really care about here and prevents waiting for other data + * not within the range we care about here. + */ + if (!code && + (ip->i_size != ip->i_d.di_size) && + (vap->va_size > ip->i_d.di_size)) { + code = bhv_vop_flush_pages(XFS_ITOV(ip), + ip->i_d.di_size, vap->va_size, + XFS_B_ASYNC, FI_NONE); + } + + /* wait for all I/O to complete */ + vn_iowait(vp); + if (!code) code = xfs_itruncate_data(ip, vap->va_size); if (code) { From owner-xfs@oss.sgi.com Mon Jul 9 14:45:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jul 2007 14:45:11 -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,J_CHICKENPOX_12, J_CHICKENPOX_21,J_CHICKENPOX_41,URIBL_RHS_ABUSE,URIBL_RHS_TLD_WHOIS autolearn=no version=3.2.0-pre1-r499012 Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l69Lj3tL027102 for ; Mon, 9 Jul 2007 14:45:06 -0700 Received: from localhost (dslb-084-057-124-069.pools.arcor-ip.net [84.57.124.69]) by mail.lichtvoll.de (Postfix) with ESMTP id F2FA75AD54 for ; Mon, 9 Jul 2007 23:17:28 +0200 (CEST) Content-Disposition: inline From: Martin Steigerwald To: xfs@oss.sgi.com Subject: Fwd: xfs_fsr and null byte areas in files (REPOST) / file data checksumming User-Agent: KMail/1.9.7 MIME-Version: 1.0 Date: Mon, 9 Jul 2007 23:13:48 +0200 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200707092313.48876.Martin@lichtvoll.de> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12095 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Status: O Content-Length: 20304 Lines: 480 Hello! I am reposting this, cause I think its an very serious issue. What I experienced here is quite randomly spread *silent* data corruption. Not meta data, but data in files, but that actually doesn't make this less severe. I really like to hear some feedback on it. I will clarify on this by asking some questions on how to efficiently try to reproduce it and detect that it happened again. But first I summarize what happened and add some more information to it. It started when KMail detected broken index files after I ran xfs_fsr and rebuilt them[1]. I suspected it could be an issue with files that were open while xfs_fsr ran. Later on I detected a broken hg repository. I still suspected that I might had used this while xfs_fsr was running tough and did not take the time to look deeper. But then more than a week later I detected a broken Bazaar repository as well and when I checked all my Bazaar and Mercurial repositories via script lots more of broken ones. Then I checked for other broken files and found hundreds of them. I also analyzed the kind of corruption and found null byte areas where there should be data in the files I looked at. Just the in this case intelligent standard behavior of rsync not to comparing every byte of files whose date and size didn't change in order to decide which files to backup saved my backup from being corrupted as well. That made it possible to at least recover corrupted files that were unchanged since my last backup. It still is possible that I have some corrupted files that have changed since my last backup, but there is no way anymore to fix them. Now it seems that at least some users use xfs_fsr regularily[2][3]. Johan, did you ever check your files for consistency? If you have a usual rsync backup of them a rsync -acn would do this without altering the backup. I also thought hard whether I am facing the issue with binary NULLs in files that is described in the FAQ[4]. But I halted the machine regularily after KMail found those broken index files in order to boot my OpenSUSE installation to run xfs_check on affected partitions (except OpenSUSE itself). Thus I actually think I got a different issue. I now also checked such a broken file - I still have those broken repositories around for holes, and well these null bytes are for real: --------------------------------------------------------------------- martin@shambala:~/.crm114> head -c9183 .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit | tail -c1000 | od -h 0000000 d46d 2b8b 9b50 5ce8 00f7 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 * 0001740 0000 0000 0000 0000 0001750 shambala:/home/martin/.crm114> xfs_bmap -v .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..23]: 32065584..32065607 5 (4599184..4599207) 24 --------------------------------------------------------------------- (I did not copy the repository before I rsynced back the good one, I just moved it with mv.) I would like to reproduce it and have some questions on how to do that efficiently. I have a spare 1GB on my notebook harddisk and also a spare 10GB on an external USB drive that I could use for a test partition. 1) Is there an XFS qa test available for xfs_fsr? If so I could use that one. Are there some hints on how to get started on XFS qa? 2) If not, what would be the most efficient scriptable way to produce fragmented files? I would like to copy some directories to that test partition in a way that produces lots of fragmented files, then run xfs_fsr just on that partition and then compare the data with the original data with rsync -acn. For an xfsqa test it might be better to use md5sum (since it saves an extra copy of the created data) tough. I strongly recommend to add a xfs qa test for xfs_fsr. Is there a test that verifies file data integrity after files have been shuffled around? And least but not least: Are there any plans to put file data checksumming code into XFS at least as an option that one can enable? I think modern computers have enough processing power to handle efficient checksumming algorithms without too much overhead. It would be nice to have an easy way to detect whether the data of a file is still consistent or not. I found most of the broken files via rsync, but only those that have been unchanged since the last backup. I have no means at all but searching for null byte areas in files and judge whether they indicate brokenness to find any remaining broken files. Since there may be files with legitimate null byte areas I may not be able to tell at all whether a file is broken or not. The percentage of files are affected is quite low and thus I just may have luck and will find no more important broken files over time. [1] http://oss.sgi.com/archives/xfs/2007-06/msg00242.html [2] http://oss.sgi.com/archives/xfs/2007-06/msg00416.html [3] http://oss.sgi.com/archives/xfs/2007-06/msg00148.html [4] http://oss.sgi.com/projects/xfs/faq.html#nulls ---------- Weitergeleitete Nachricht ---------- Subject: xfs_fsr and null byte areas in files (was: Re: xfs_fsr - problem with open files possible?) Date: Samstag 23 Juni 2007 From: Martin Steigerwald To: linux-xfs@oss.sgi.com Am Freitag 15 Juni 2007 schrieb Eric Sandeen: > Martin Steigerwald wrote: > > Could data loss happen when running xfs_fsr on files that are opened > > by an application? > > It should not; fsr performs a lot of safety checks and aborts under > problematic circumstances. It will skip files if: > > * mandatory locks are present > * file is marked immutable, append-only, or nodefrag > * filesystem is shut down > * change/modify times have been altered since defrag started > * original file is mmapped > > If you can clearly recreate it with xfs_fsr, it would be interesting to > compare the good & bad index files to see how they differ, it might > offer a clue as to what/why/how it changed. > > > I did not came across any other corrupted files except a Mercurial > > repository. I can not pinpoint this problem to XFS at all and have no > > idea how and when it got corrupted. At least in my backup from some > > weeks ago the repository has been okay. Unfortunately I do not know > > anymore whether I made a commit to that repository while xfs_fsr was > > running or not. But I think I didn't. Hello Eric! Well I now found lots of corrupted Bazaar repositories as well. For all except one I had a working backup. Those were definately not in use while xfs_fsr ran. I can't prove the corruption to xfs_fsr, but except for another XFS failure - which I doubt happened - I can't think of much of else. Granted I used some beta versions of Bazaar, but not on all of those corrupted repositories. I tried to reproduce this with my good repositories from the backup, but couldn't. I bet that they were not fragmented. xfs_fsr **/* (which recursively matches all files on Z-Shell) in the directories of them returned rather quickly. It also happened on a second notebook. I have a T42 and a T23 and it happened on the T23 too. I had a closer look about the kind of corruption. Only the file content seemed to have changed, not the date of the file or its size. Thus I was in luck cause rsync simply didn't copy the corrupted repositories to my backup disk. I found out about this as I tried to rsync the corrected repositories from my T42 to the T23. rsync would not copy them. But when I used rsync -c it copies some files with differing checksum. One example: --------------------------------------------------------------------- martin@shambala:~/.crm114> rsync -acnv .bzr/ .bzr-broken/ building file list ... done ./ branch-lock/ branch/ branch/lock/ checkout/ checkout/lock/ repository/ repository/knits/ repository/knits/22/ repository/knits/36/ repository/knits/36/mailtrainer.crm-20070329201046-91b62hipeixaywh9-5.knit repository/knits/3d/ repository/knits/4a/ repository/knits/4a/mailfilter.cf-20070329201046-91b62hipeixaywh9-1.knit repository/knits/76/ repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit repository/knits/8c/ repository/knits/8c/shuffle.crm-20070329201046-91b62hipeixaywh9-6.knit repository/knits/9c/ repository/knits/a9/ repository/knits/c5/ repository/knits/c5/mailreaver.crm-20070329201046-91b62hipeixaywh9-4.knit repository/lock/ repository/revision-store/ sent 2335 bytes received 368 bytes 5406.00 bytes/sec total size is 86288 speedup is 31.92 martin@shambala:~/.crm114> --------------------------------------------------------------------- Those files are differing - one example: --------------------------------------------------------------------- martin@shambala:~/.crm114> LANG=C cmp .bzr/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit .bzr/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit differ: char 8193, line 22 --------------------------------------------------------------------- The good one: --------------------------------------------------------------------- martin@shambala:~/.crm114> head -c9183 .bzr/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit | tail -c1000 | od -h 0000000 d46d 2b8b 9b50 5ce8 e3f7 964c 6b3f 728b 0000020 8541 e12e f328 92a5 7061 2981 6232 7463 0000040 6583 0421 b568 481f f5db ce4c 6924 8b55 [... lots of data that looks like the first three lines ...] 0001700 a28d 2b64 d792 6dcc 96cb 15c7 f960 7e26 0001720 dc22 1d2d 6a0e 6ce0 3648 a050 c7ec 371c 0001740 743c 2502 e5e4 e1d1 0001750 --------------------------------------------------------------------- The broken one - this really looks like the null files problem!: --------------------------------------------------------------------- martin@shambala:~/.crm114> head -c9183 .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit | tail -c1000 | od -h 0000000 d46d 2b8b 9b50 5ce8 00f7 0000 0000 0000 0000020 0000 0000 0000 0000 0000 0000 0000 0000 * 0001740 0000 0000 0000 0000 0001750 --------------------------------------------------------------------- I checked at least one of those files with xfs_bmap and it was no sparse file, these are real zeros. I am quite a bit confused by that since I cannot remember that I had any abnormal write interruption while the xfs_fsr command was running or after it has finished. As I found out about corrupted files I just rebooted cleanly to my SUSE installation and ran xfs_check on the partitions I xfs_fsr'ed which turned out to be okay. Also certainly not all of these broken repositories had been in use while any abnormal write termination happened. I am doing checks for other broken files now: --------------------------------------------------------------------- find -type f -and -iname "*" -print0 | xargs -0 -I{} cmp {} /mnt/backup/home/martin/{} --------------------------------------------------------------------- Better with that one: --------------------------------------------------------------------- rsync -acnv /mnt/backup/home/martin/ /home/martin/ --------------------------------------------------------------------- Oh well, there are other files differing which should certainly be the same - since I didn't touch them in the meanwhile. And they contain zeros where there should be data as well as far as I looked. So whatever I faced here its a real corruption issue! And I know I will continue to use rsync without -c in my backup script, cause that prevented the corrupted files from being copied to my backup! Well thus maybe is a bad interaction between xfs_fsr and the null files problem or a problem in xfs_fsr... I for my part will be very cautious with xfs_fsr in the future. If I manage to take the time I likely will create a XFS partition in that one GB that is left on my harddisk copy certain directories in it simultaneously so that it hopefully creates some fragmentation and then run xfs_fsr... I hope I will be able to track this down, cause its really bad behavior. Is there a xfs QA test which tests xfs_fsr? I think there should be one, especially as this tool does not seem to be used that often out in the wild. Preferably one that copies lots of data to a partition in a way that it gets fragmented, md5sums it, runs xfs_fsr and then compares the md5sums of the files. If anyone else has time I suggest tests on that topic. It seems that something is going really wrong here even when I cannot prove it right now. But maybe it was just a rare race condition. Well see. I hope I will be able to reproduce it. I ran xfs_fsr --------------------------------------------------------------------- shambala:~> LANG=C apt-cache policy xfsdump xfsdump: Installed: 2.2.38-1 Candidate: 2.2.38-1 Version table: 2.2.45-1 0 500 http://debian.n-ix.net lenny/main Packages 500 http://debian.n-ix.net sid/main Packages *** 2.2.38-1 0 990 http://debian.n-ix.net etch/main Packages 100 /var/lib/dpkg/status --------------------------------------------------------------------- on Linux Kernel 2.6.21.3 on my XFS /home partition back then. Since images, music, mail files, movies and stuff are not automatically checked for corruption and since not many files seem to be affected I think I didn't notice other files to be affected. Will likely take quite some time as I changed to many files since my last backup... OK, now on to recovery: - xfs_check xfs_fsr involved partitions - they are fine - xfs_check the backup partitions - they are fine tough The most automatic way to get things recovered as good as possible is to rsync my current data to the backup partition *without* determining changed files by its checksum. Then rsync the updated backup back to the work place *with* determining changes files by its checksum: --------------------------------------------------------------------- shambala:~ # rsync -axv --acls --sparse --delete /mnt/debian/ /mnt/backup/debian/ shambala:~ # rsync -axv --acls --sparse --delete /mnt/debian/ /mnt/backup/debian/ building file list ... done sent 10306228 bytes received 20 bytes 38818.26 bytes/sec total size is 8376658632 speedup is 812.77 shambala:~ # rsync -acxv --acls --sparse --del /mnt/backup/debian/ /mnt/debian/ | tee /home/martin/XFS-Probleme/2007-07-23/rsync-acxv-debian.txt --------------------------------------------------------------------- Now look what is in "rsync-acxv-debian.txt": --------------------------------------------------------------------- building file list ... done .kde/share/apps/kconf_update/log/update.log [ ... above one shouldn't be here at / at all of course, however I managed it to be there ;-) ... ] boot/grub/default lost+found/8937921 lost+found/8937923 usr/bin/nslookup usr/games/gnubg usr/lib/libGLU.a usr/lib/libclucene.so.0.0.0 usr/lib/libdns.so.22.1.0 usr/lib/libkeximain.so.2.0.0 usr/lib/libkoproperty.so.2.0.0 usr/lib/libkwordprivate.so.4.0.0 usr/lib/libpoppler.so.0.0.0 usr/lib/flashplugin-nonfree/libflashplayer.so usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 usr/lib/jvm/java-1.5.0-sun-1.5.0.10/jre/lib/charsets.jar usr/lib/jvm/java-1.5.0-sun-1.5.0.10/jre/lib/i386/client/libjvm.so usr/lib/jvm/java-1.5.0-sun-1.5.0.10/jre/lib/i386/motif21/libmawt.so usr/lib/mono/gac/System.Data/1.0.5000.0__b77a5c561934e089/System.Data.dll.mdb usr/lib/python2.3/site-packages/PyQt4/QtGui.so usr/lib/python2.4/site-packages/PyQt4/QtGui.so usr/share/X11/doc/hardcopy/XKB/XKBlib.ps.gz usr/share/doc/aircrack-ng/injection-patches/linux-wlan-0.2.3.packet.injection.patch.gz usr/share/doc/dahb-html/html/bilder/allgemein/debian-devel-earth.png usr/share/doc/dahb-html/html/bilder/allgemein/openlogo-nd.png usr/share/doc/dahb-html/html/bilder/sarge/sarge1.png usr/share/doc/dahb-html/html/bilder/sarge/sargebasec17.png usr/share/doc/dahb-html/html/bilder/sarge/sargebasesecurity.png usr/share/doc/dahb-html/html/bilder/sarge/sargedomainname.png usr/share/doc/dahb-html/html/bilder/sarge/sargehostname.png usr/share/doc/dahb-html/html/bilder/sarge/sargepart1.png [... it goes on like this ...] --------------------------------------------------------------------- This is nasty. Some of those would have been very difficult to find. Heck that flash player even worked OK yesterday on YouTube. Luckily not that many files seem to have been affected (aside from those broken repositories and KMail index files I alread fixed): martin@shambala:Shambala/XFS-Probleme/2007-07-23> wc -l rsync-acxv-debian.txt 117 rsync-acxv-debian.txt martin@shambala:Shambala/XFS-Probleme/2007-07-23> wc -l rsync-acxv-debian-home.txt 232 rsync-acxv-debian-home.txt Well at least for me T42 I recovered almost all important data. One Bazaar repository got lost, but I can get the version history from someone else. And there is a slight risk that some of the files that I already changed in the meanwhile have zero byte areas as well that didn't come to my attention yet. Well that shows me that a checksumming filesystem would really be good! It could have told me that file contents have been corrupted during check. And I learn quite a lot: - if there is any slight chance of corruption (that corrupted KMail index files) check it out before doing anything else. Just do not assume that its only those files that have been affected, but check with rsync -c - if there are broken files, restore the backup before doing anything else. Except that I have spare storage where I could store the filesystems with the broken files first for further analysis. That would have helped me to have next to zero data loss and it would have been way quicker to restore everything to normal. And another one: - do not try an online defragmentation on valuable data before testing it first on test data I still can't prove it, but I am quite sure that it has been xfs_fsr maybe in combination with some XFS problem. It was the only tool that could have accessed all those files. I know for sure I didn't do write accesses on many of them. Some more information about my T42... Kernel version and Debian installation on my T23 are pretty similar only drivers differ a bit: martin@shambala:~> cat /proc/version Linux version 2.6.21.3-tp42-cfs-v15-sws2-2.2.10 (martin@shambala) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Sun Jun 3 21:43:50 CEST 2007 shambala:~> xfs_info / meta-data=/dev/root isize=256 agcount=16, agsize=228894 blks = sectsz=512 attr=1 data = bsize=4096 blocks=3662304, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=65536 blocks=0, rtextents=0 shambala:~> xfs_info /home meta-data=/dev/sda2 isize=256 agcount=19, agsize=686660 blks = sectsz=512 attr=0 data = bsize=4096 blocks=12695508, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=5364, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=65536 blocks=0, rtextents=0 Ok, I am quite exhausted now. And there is still the T23 to do... (in progress at the moment). Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ------------------------------------------------------- -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Mon Jul 9 17:50:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jul 2007 17:50: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=1.8 required=5.0 tests=AWL,BAYES_60,J_CHICKENPOX_66 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 l6A0oabm014866 for ; Mon, 9 Jul 2007 17:50:37 -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 KAA02670; Tue, 10 Jul 2007 10:50:33 +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 l6A0oVeW18151308; Tue, 10 Jul 2007 10:50:32 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6A0oUTw18153336; Tue, 10 Jul 2007 10:50:30 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 10 Jul 2007 10:50:30 +1000 From: David Chinner To: Martin Steigerwald Cc: xfs@oss.sgi.com Subject: Re: Fwd: xfs_fsr and null byte areas in files (REPOST) / file data checksumming Message-ID: <20070710005030.GQ31489@sgi.com> References: <200707092313.48876.Martin@lichtvoll.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707092313.48876.Martin@lichtvoll.de> 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: 12096 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: 3832 Lines: 95 On Mon, Jul 09, 2007 at 11:13:48PM +0200, Martin Steigerwald wrote: > > Hello! > > I am reposting this, cause I think its an very serious issue. What I > experienced here is quite randomly spread *silent* data corruption. Not > meta data, but data in files, but that actually doesn't make this less > severe. ...... > > I now also checked such a broken file - I still have those broken > repositories around for holes, and well these null bytes are for real: > > --------------------------------------------------------------------- > martin@shambala:~/.crm114> > head -c9183 .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit | > tail -c1000 | od -h > 0000000 d46d 2b8b 9b50 5ce8 00f7 0000 0000 0000 > 0000020 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0001740 0000 0000 0000 0000 > 0001750 The corruption is not on block or sector boundaries. Given that fsr uses direct I/O this does not really seem possible. > shambala:/home/martin/.crm114> > xfs_bmap -v .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit > .bzr-broken/repository/knits/76/maillib.crm-20070329201046-91b62hipeixaywh9-3.knit: > EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL > 0: [0..23]: 32065584..32065607 5 (4599184..4599207) 24 > --------------------------------------------------------------------- Can you use xfs_bmap -vvp so we can see which of those blocks might be unwritten? I'm trying to reproduce this at the moment, but I haven't been able to yet. I'll let you know if I do, but given that we've been running fsr on machines for years without having seen this I'm not hopeful that I will be able to reproduce it.... > I would like to reproduce it and have some questions on how to do that > efficiently. I have a spare 1GB on my notebook harddisk and also a spare > 10GB on an external USB drive that I could use for a test partition. Copy the directory that regularly gets broken to the spare partition, and run xfs_fsr over that to see if you can reproduce the problem. > 1) Is there an XFS qa test available for xfs_fsr? If so I could use that > one. Are there some hints on how to get started on XFS qa? Yes, test 042. Download it from CVS, build it (installing all the bits it asks for ;), edit common.config to add your test and scratch partitions (both volatile) and the 'check -l 042' to run test 042. > 2) If not, what would be the most efficient scriptable way to produce > fragmented files? I would like to copy some directories to that test > partition in a way that produces lots of fragmented files, then run > xfs_fsr just on that partition and then compare the data with the > original data with rsync -acn. See test 042. > For an xfsqa test it might be better to use md5sum (since it saves an > extra copy of the created data) tough. I strongly recommend to add a xfs > qa test for xfs_fsr. Is there a test that verifies file data integrity > after files have been shuffled around? Test 042 uses checksums to determine the file contents are correct after the defragmentation. > And least but not least: > > Are there any plans to put file data checksumming code into XFS at least > as an option that one can enable? Eventually, yes. But given that it is major surgery and requires format changes to extent btrees, the write path, the read path, and so on, it's not going to be avaialble any time soon. Besides, this problem may not have anything to do with the kernel code and hence checksums would not help find or detect the problem. i.e. checksums don't help you find programming errors or bad data written from userspace. Checksums are not the Holy Grail that prevent silent data corruption. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Jul 9 20:53:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jul 2007 20:53: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.6 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_66 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 l6A3rWbm005173 for ; Mon, 9 Jul 2007 20:53:35 -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 NAA08704; Tue, 10 Jul 2007 13:53:27 +1000 Message-ID: <469302B7.7090306@sgi.com> Date: Tue, 10 Jul 2007 13:53:27 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Martin Steigerwald CC: David Chinner , xfs@oss.sgi.com Subject: Re: Fwd: xfs_fsr and null byte areas in files (REPOST) / file data checksumming References: <200707092313.48876.Martin@lichtvoll.de> <20070710005030.GQ31489@sgi.com> In-Reply-To: <20070710005030.GQ31489@sgi.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: 12097 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: 587 Lines: 14 David Chinner wrote: > On Mon, Jul 09, 2007 at 11:13:48PM +0200, Martin Steigerwald wrote: >> 1) Is there an XFS qa test available for xfs_fsr? If so I could use that >> one. Are there some hints on how to get started on XFS qa? > > Yes, test 042. Download it from CVS, build it (installing all the > bits it asks for ;), edit common.config to add your test and scratch > partitions (both volatile) and the 'check -l 042' to run test 042. > Yeah, get the xfstests package and read the README in there. If the README is not clear or you have other trouble then let me/us know. --Tim From owner-xfs@oss.sgi.com Tue Jul 10 00:36:28 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 00:36: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.3 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 l6A7aLbm008685 for ; Tue, 10 Jul 2007 00:36:23 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14439; Tue, 10 Jul 2007 17:36:16 +1000 Date: Tue, 10 Jul 2007 17:36:47 +1000 To: xfs-dev , "xfs@oss.sgi.com" Subject: REVIEW: Updated all xfsprogs man pages From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------Rr7cg5yEJuo975mRgBBBmL MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12098 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 69742 Lines: 1152 ------------Rr7cg5yEJuo975mRgBBBmL Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit - Updated out of date information. - Updated formatting to linux standards. - Improved readability of some complex sections. ------------Rr7cg5yEJuo975mRgBBBmL Content-Disposition: attachment; filename=updated_man.tar.gz Content-Type: application/x-gzip; name=updated_man.tar.gz Content-Transfer-Encoding: Base64 H4sIAFQ2k0YAA+39a3fbVpYujNZn/AoM7X1OqN4ULcmynUp29TiyrSR6y7eW lLrsJMcDJEEJZRJgAaBk1agf/877mgsAZdm51O5uq7tiiQTWda655vWZkwer rHz44Cor58t88vB3v8bPPvw8PjrCfw8PDw7w34MnR0/oc/j14eOHT353AE8c Pnx8ePj40e/2Dw6PDo5+l+7/KqPp/GyaNqvT9HfTMtv8rXq39bl1e/lbDOe3 /plcfJd+d/zq+YuT9GEyOf8ufXX88iRZZ+3V27Z6y2QxTvXvRaOfLOb+e/43 fqJa5+Xb6a09U+fZfFmU7/xnWdvWb1ebZVv0Pl0WTes/XDRN3s5X0Ud1ntsf l3m7zuq8bBv/iH2KM3DfpD/upYsC/pU/YbB11hZV2dAiPEvP//rq9Zvz0/Nk 8jT9H0U5W27mefq/m9vmQXu7zpvJ1b8nk2kdf/t+0ehBwq+/ewNfn6Y7Rdn+ mMYrOppdAdH92w59nO6M0+uqmKf/Bh/A92v8oCn+AeuJj1wt8zLd/XpLe7re P79Fv6Mj+CTdgY8+qaU+NYy4jV4T0oLvhF5Zp2NuL3QFnw92FpPZhzvimVWL ZXbZb6xPo/cd+U463Sw6o4bPmn4fQzT/Sb3wTOq2vp7hbzo1nNm2buND9eFe lagG57ZZwO/dfrGVtt7MWuqQ+ptt6qaiZuS3Pul1z/aHRyadLJr5qphnbbZD zf2bNhX1gY396LnFB5rvjW+It3x4iPwKU+/dCyhP8vLwC7JU8OWmbIrLMp/T MuM31QZ+kca6X66qOr9j/B0ueP856PLiPPxznzIHbYsnMjBDmwRw4ucn58/O Tt9cnL5+lVxc5U2eLjbljDh1uq6r6wIYb5beZLdpW6XAxBdVvUpned1mRUkc Hlh2m688g78p2qtq06abpigv4WW6B+Z5M6uLdQvjhYay2Sxvmuj96d/yWdtM UhjEbQpzTWCweTmHUUOX0FaeTuHzdFmsihY+BCoEJpPK25u2WBZtkTdps5ld pVmTTrPZu806gSlc1tnKtQtPrNdVjW1U5fIWW22v8vQv35y74UySF8ClUpwJ fovX0LKY8qYm8Fud1bduHm28cJNk8uZNcix8Gijp9CwVprspi79vcugW1rVs iwUOOeuvQwpTzsoUH4ER+3HBNOCTooHBw8aUMgn8Q25a2Ieovbrf+iT5jp5t gESANBpeyWqVp+VmNYX34c/pbZvzqhEx4keZdJGMikk+oVXrPA/trdZ1Qfte tLvpdVbjBGWJ8WLHR6UVHPwK6Ooa1xL3eF4sFjkSuRIDPowvNtmK36bp46Bb eioMiRZkncHS0q6s18tilslenIP8YKuDc2m4S+wfWi9qbbAh8uBmxsmVLBF+ xsQ7BZLBqdxU6d83GWwNEhxIU+m6QloFYeXsNB3JWd+l9jNevJEyPp4AfiZU gZ+OgdTnON68GVxUOGj4sczg5qpACodRcbdznLGssAyE6e+C6PasIxmlo91E CRWu43ZTl41vHjcC/xQ6vCyuYYTcPIyYGkuy+nKzggWbpKe8QYuizJa0+UCI vDM0HBSVSty8Aqm8uV1NK9iYFCWAceI65XEgg8KxZNYAPgiE1OTLxfCcVP65 76zcUYBV5aW872yh3QZObROPxEt1H7m2dU7kPhOy4i4Xc+twLANcgQqVTpEN X2dLuE86/DQeT182/GXWJumNVt/vLhrSPx5u+h3o2+bTDK9gLGBGo8WvmoEb 5M6FVJ4wSU5bIjygzeqy2jR0IpnvzoBc28q6T0eHu4ky+zR/P8vX3P+CODz8 AQxNGUJRwhplc/zSCLwzpb6Yu3UTjPcQN4uOyNZ5+a6GpN2os1VWFuvNkrgL PbeGB+A6renVYrrBL+C5gVvonisYhrBIRw93E14/PsieQTfrfIY33twvYW9z B6YXS9Vbl5I2QllHb4aLnztDHMUvP8GeaB5ND75rVACZF2/nq/x6lTXv+HjJ R00Le5tAt8s53RUgN6AwU5V786IB9llWc7itu/OES6OVIezA429PXz97+835 +cnF85cp6NmzdrlDcwWmDhQ0H6efMOnOTIN+EM0RP+cNbGB1sktgdMtlhdch i3567uySEPazqOCxGziZ1lTz1fCFN952Z4yHWPhYVncLL40nNaS5DBIo7EpW 1yDuVAvcOZX7E9azNsAZabJ5BlwXlEJiH7JJvIXQ0hqeyunKlyVg1qts4YKu XBKgrFUQIWfwciP3MX3JzbGUgRacUiR3FTxw+vj4NIPe8PZ2t/EEB39xBftu M4Tfy6oNCgAcG/gU5OfN+y1r1bUV+fWC1vzxMyL94EJ7+nSUyOuP/DuaUtFG rIMuei90bNa6+CvSokiyGp58tmyqu1YAlKyzk4vvz16lfzp+8f0JbZO+P3Qw rjJc0HSRFUvcQJEN4WGWxisYVO2UNJ4GDRXEAxCA93XZYAWXOHHQgUhLKWh+ t6gizfJ8/jU3dVM0+Zi/6DX1494BMURgQ3ib53VdVgm0rvIqX5d1TUwN5nly dvb67DyZXKBynJ4cP3t2cp6c51kNRA2LsyqaBhftBmYIe1zIAc8iyZHkYrpY J9bQ0+Pn34hwJNSmshBpQHiD95msvPvN8fcvLpJjPH4ixzm5GU5lUUpL8zkc rya8ePoK9sukwIJ5q79CiNTmVc4jErVyQBeU9l68fg1noarwRr6Nb/omvcnl rG5QgCdmmrZ1VjZwcSvxmrQR2kRj8sXr1y9ev/oW9M3OMgpVs6gkqiTIY5fQ ivsez00+j3Rx0rHdyF+9Pnl1sa19W4D8PVyQ4aU3J2cvWV0DMgSKteeusmtU wheLYlbQdtTFNfR9SUIUENH5yUl6/OL8dSSdjSO5KnwSZA+8rcbxbR0+4hst +jsdPQJe/uvb/9n/wwP4l/h/jo4eP3oo/p8njw+fsP/nyWf/z2/yg/4fkK+e Xbzw/h+hxx/3SP6vq2XH/iRyKLDZ62K+gfuEvrrTdYLOEfhf3zPCfY3Q1NOm XS+G90Pw77PV3NvD1y3bk9+EJtM1MCW0A74Fwbp9C+2/XcyDRwOfJs/N1qex 86HxDJgkz9EqpcwU+HR7qwLnTC/oeOXoRiarXDFdojUo8dYgeKGuNpdXNqg9 a01eR26VkhVlkc2QJbFRNJg34YkStXHaGrapVmQTanK5kWFXnTWU7Rn0d45i QXdTx3qH1TbE6IWkq5uzOSR9RrbMq2qznONw2uxdjlp7jjJJs0Gx2DO+XZIG SOwHlRrlCrLIwZ2Yt7z4OIqunj2agohA9odkyobTJVzau8DLcRpwbQShVPWc RV2tVAXp2C1pQKitIPMFhVvF7IX7zO2CrTSocnRZz/MWZYgSbWA5SUEwRBIG 8HKfFi1aZcm1qlZPP5dpvqzwIq22jA42GVcU28N7PEPquapu8msUkhsmNaAd uI3xIKI+MXAKcKF1WsN0j08Eu7qRIS7nGs3dsJKrHE5FWTQrvA/P029wIq8D QZ2WML15Tnb0fLFAA0hWBgIiXb5HZmOTIFCAINurW5tgoVlnDa82MhcmnsSZ qpUWYTVRKhEqRSM0qx9sCDRJy9lNYfVv2KChumf3YVKMjGInyTEcRBHJ0QGV Ok2JTcezumpSfBVmbV2wuRaaFhkKye7sNP3fqfDHt8gi039PrkCUEEv5RLhb qnrw8YsXr5+dv1EHdOfjx0fdL745OznBx988T/dV/om/g3eOl0C9puI2a+Au KSx2NStoBcn6lCkT0YnDRsMiAVXTopuqPUnZMJ+bEhK0cLIUoeGdKBjbuV3n urJvF6BZv3t89BYdXH37cbwjvKW09tJG3ESCd1dWiApl6jhsCaqRpIyny7fI kmY5ys/74/RgjEfzMI11iKzl05WjsHuNg16QxoGvo/TQJjcFEAOwglWeIfOa M5thmwF8r8sVKH22qWuW9ZsC1wj7TVgOnsdPAz2tcR2v0StDno2x77ng2fGQ QrfabmT+oFXWGaOxX8zj8rJ7tIHJLCrhwjpWGRoPC3UEXHpgFvl1UW0aGN1N XbQtMni6clAPdRQAKiMyONTf7fr7wAhuK3aBDI9AlwiX4LKubkq9IpZKrv/I 60quSF4ytPaSIQrbl0bR13VZwlznfNOFKwtHBBPBViYJrV3npKXjoU8fH9Hn 3dMnJrHeuXM3K/IGut7VwIDddo4rm8BAaWWadEY3Gn2wuKUfsLjR4SHnHOg2 QCsrfIfU6kbt1401khEpVE3utzt4RUq1AU6bng2QPopsgELe083yHX4eGKc7 0MSJ6zsOP8lRbB7shQKk2BBSnzb8RaOHnjy3MCp4uDvSM/mQV0/G4myaRjhC F8EMISfLt+nfd9vx4ddD7wW5K1ckaJNroq2LmfDDuqrIB4s+b7aewK4Rzc9h e4CdwWvAxmmhZtk6m4r7Ge3JMIIK/bCbGpgEmUhR5kDmKE5pIiTsDxmAOqip V/kMNztD9hAuN7hG2SQWEZmQT5+Mn5++Pn31zevk2xyNYShhZGKN/PumkG1X Z/4cPoDtPX3wGkUH4qnGJuj8e6vK8/AwTEyayOfSyJKd4qXw54ys8EAcRHLT Dbp31R+L/bzLgbyX8D1/BSs5u8pjXjbN25s852GBkE1cKem3yj4yuI9oRrL7 5jbGE0HqRg23Fbp5m8QWggxQzDApWKHOblJa4DVwf2Lxg5IN3Z28s8OXrZ6a eVGhPWIHeBa71O5xac7fwl9688CvFXqrl8BFxQ1JQ185R+vQMnM7RVlUzT8S 3VFYary92QOd4rerzYp2E1sF8pNvcAvxU+s1OK7JvA9M1L3UOBeluZhoaMhE 2ICqRmU+kurYz/N36rRORQoATmnf+4GRFkK2VuyHLsH8knZ+sENdgOw9LYAu Jvw5NGNxd4rCEchaDkTvGMC1Co/6Vsy8tcpzNQI6mhubIRttWKTqVDX9jZd6 Lg5IWFY0+zKnYQMky8HRYuNl8Q5t3RK9gYTA4qPIDOmUlNyWBAVadT5Z8lCI WmFdOINxI1exk92zpfZvyW9PLv5yfHFxRhwmm88LsXs7j1tXuCV9C+8yVb5E 5W5+3gFbNO/DAasady+TYeQrvo3egwKG8XPJKH+vYUUYoQhaY0M2QXoGvkNq SEZltaLh0MNCIhLvpIYCOkju3ZKfhR5C/AZthnyuYRzYBoiGx90++WC4Oz+E hJDHbW1Xth8UmtKDyJBQVFToZ0xXeNQNjAoFrm77JOvkiwwOk4on8KkzO6gE jsr4JHlmsh2zqAw9LIvNktZTxZvOyvMFDcT7lWpK7CpIDyb7BWi6L9Odp0Wb 7qej/fcHu2hFQXL7yzcvjr99e3Zy/OLi9OXJjpDKUkJK4DAtiWGIHodkqg0d YEOHnYbeYEsgRrqGrngJg9ORdLNOYw+xsS87jZ2+fPn9xfHTF51hFavVhu0H e+hnAqaCfAG1l2pO1+oYlnqZk95cwxRQI5+PE7z00LYtTGgGQxJphNgatY58 GZ4jupLnVCkQpw8vxOtStqbZADMjXzg5WtQVBJJJI1cePvXs+M3bF6evvv9L mFJiYs0t9USUBVf0Ms9qGRDsameVjmjv9jvLdPzmzcmr552tW6O1Y4/kY10l icfL2eiPcjU9hMtGUSoJThWG/C+b3iOiqO70zv/6CsgJuTSxcmfeWLJJqbkt Z8BqSziinQYfY4NH3QZfvT5mWv/zVR7OcjBsIgHhMcuI8oFrV/VcvbBKYp2O nhD59jt6/v3LN25jnG72roDFJ2uCCK0WYtlp+kve827bZxenr747OTu92EnO 9JAW5VUOS5Sh/AeMAja+zG/kXlByFy7JtxEIPqb6Z5u2QikWTYO3dvBZVMFm 9I0iaiyJGmMuJsMQ13o0pM7cfs8b3p3bm7PX/4/N7k1dURDSXZNjzfFTxic+ b6Rs6uX0+SRNX+U3iW+OpKLoreExdRnkPpNfnyzO//oSzssfz3eSZ+5YyuWS ufHyxBrSbmRabL1KOv5N2lZ0l+qr3bEcMIV2x3Lyl4vz0/8DZ+HEXXq8vAWG mUyzBvrwN6LofE3auQtxpfkv4fRw3Gm5lfHjGFWYDKGnuTS7IPuR8uERSK49 swELRGSG3O1O71BOydD8/o/R0kkkbvya9LRt3e4xsbtJojvxh3KEBnjPyTdn x9/uJK/Qsr+os0uS+9i6TPNtt7Ol+aZmdS28SZQXrD2TlLhnxi4LliNtkON7 rCUuXeKXrqx+3OPuhs7SkZyl7jy/OX1xcn4BUsfLnQQt+SC15tnK0SDPVU6Q P1tsEMjra1J35AWc4yWI7WuOFnoPMm6DJlOJj495KYrd/YNHDoUmYQt+MClK YIlfCqIevFWwddOoeyMhq14lfUufIZZ7sEHS+OCuvc4TFY+rkvRuDnLhiWdq 2yRyy8hIi5raMte9q8UTkeiUcSwdM2m+lTgfKtOhn87GfXd8jmTfERRNe7hD 0SHiODthr8Kb53doT8fJaRxqOKRh+cAmJ1WbvsFydWRWCBqIDXNIDdli/uRu z/8vUuygX6aB2GbijKfkI6SpoVkPSLSr9wUbpOlCqVmu3XORRkGHU/IE6IMv mohnYvoCiupXWXkp+STJTVdoy1fr9tbiJ2X5Z1kjORWOWWNqBzspXB8i5iOn RT0QVHwa3ohmapcdrQ4uQrIgneJys8zEBxrOa0OOTOGm21k4cD0kp79pjJsF Rg9fWyQp7/ZpCQj46cvjN2QhIHs0WZ5W2VqCvpr8Um1Y4jsOpnRHRR8iIoqr xLBKo6ZmkJwu83YKne+IZ5ETQcj1Tr4ROxghdDKj6Lt0UxYcnv0IbnFOi2Fj mD04YHGYrq7fihtrRJMRDwwm2vC82XKAz9HCJCPyNyFZ80INPcnRW8nIorj6 j1AEmbdBcNQpPFNTtgoPUjWjRVE38HKqvgRoQJ70TchH6vspyl3dlLrxsaay gtwj6efsZR3bGarzFTApZNjOmxu9JnzMUYu3X1tALQ9AnLgSQwMttXT7X+ep RTsIx+wSpVj+Jz5CDaeno+nsoVsf2YPY1yID6YZGAgVl+Ahdd2gldMyXwowH ++QtZLbebTHsvC2ZOvk6A4zkYGgGYzlNBI6b0eGRSIVDFmspfpY4Zykq3hok KgZ+XLqxXwJ4dbOesx2lCrYl9bQwNwMuq0Ed1ZS2m1IS3U6PU80irPM9oJi2 yJbFP5RsA/HgYYZ+jC7GfiWUlHkp462KHUVbjgvKHBvSN430mWLQYCoNOUJW VdUepkkQFwq0JE5NO/hpiDcPu5eyiRkZuYsGMCmkrMT8mI74mFXL3NPWru10 zGO6PjKgia18e7tsomcojrgOhzSb4r4RfZr0Ad++i6ZRhIB+HEIcgHF2cv4n DKi4GPj08VHPd6e0ZJocR1eQiMF0e5zWeEW7nDofMqGJquqJ2CabdMIfbMH7 QROyO+JwZrviOEUxBqVf8pvPx5FkwZe9eRFYpDD/fT/GDX1dxeVGfHlky96U KvlSgyLwjRNxZ5AmqSRa5peZxDxkFEOEwhzSjNjY2PPZNYqOk4acd9B0HYdC Y6hyNgtudu9ohKFe53WrUg3nsUtgm22LrYPMAaduUStIXenoy13gGxib1YSp /uFgHLiaN1fDKVnB+RxYHFmXPtV9/2qY7vTzOygPQ/iF6oQx/vZ09wbFB40q 9D4K2hBPczfELwafgxVeVdc+wIYmwvFGd9BpMvkRJCtcN/w35hWnr9GEQ99E 63fJUtcQ4wjODnZn5uSOpCaof1p3iVvQHUcqEFInKcq9mI7yCRpz8fUWus7q efp9WbzvOL52I+91uPV45NH9RN5vjpVD+yjnBgRJyPaOV0Nl0GlR4fB36PMP h1/hU/KK3Ni8l/l7DLoUjWdZXVJaS3qoA80oeIOzPYKGcHDkTgoMR3YSvjn8 /6P14hBItdDYP2gHHzs4gqtoXd3k9a6tgs4JB/aPt+jNpE/4aiH2oiJc6yKL eBjbtg1boYhVbKi/9id80YgoQX6DxV4IUvIeKvKuRk1Q+Ac00jHtwbx5SbdM jGz5P39mwk55RatPnxd7ib1n4WOnNV8s33b2jOSO7rdh4npXODlJhiSewk44 E/ltJGhky6qyjt1Z1dDFgVKtLi5tJxpqafq81CgATfOcpw9HYVnMCvREQhvU 6zZWdH4HK2o+lhXR4aF2PokVxWyI2vklWNGvxoW+p5uqWbGiFJZEV4JjtYEp IVUUNnkUOej9YoUxzznHGBexGAhDFKeOurfkYqTumGkHDxp22SBJQCtsFuTn NM6kI2Nqk7JV1izey/OKAkGasQycUCuAoYKYgNcvxpaT5bMS9QpPTDCISRhd Rqtestsw980GYryoOnTaISxbxbF1tPXEDIZPqiS5hTe7cz7I3Jp+q6Qk2s1i cdh5Q0IdTVtb5bMp91M3npaI/eAhsYgv/8hC0Bit5fjBweM/8h0nnz6iTx8e 2nN5O5vsgvDxJ8rQE26DN+DBw72Dx0xZpZrA8d1VNrvCAH0Npz7ipuB8XOZ0 3eFCHRzBy+TQIQbaeQUGFb+jwdYmtg3MXoZGYVDkjQtHQS9uDuOAsV+SqZoi LJiHoSH/7xtLd+0JZkQbvwA/d+ZSicgNJAp6hrCFhhP0siU2e0uctku9c4FZ wdQ9xubheSyk97MBnotqLw9RTAsUzISKBRviMDcRs1F4XYyYKamQTm3nfJxq dgL+RUk7cv+TdYJSXJtmsSG24g6Hv1PNqyFsTYiccnmwN9j47zQBpFhsO5ZB mz7oX9vaBbqbmEboHVDrMcUbQxWgU81m0Qd7KwJrrGPUxUmr5TxiMOgxETur SIxCk+oDiYN7PJWJuCdiCHFOAeoA+v0UlnQY7ik2+M3D6goR6sUvhGj+YbSL h3k9I+1CNLnp7QdudAqiRkW0sHuLDq4tp6xRtCC6TJUGpRrohuBnVYEYOS6u rtaNMV5mcEh+Q1nIsvoSSUVt0OGiQzVbVnAxiWB9nhtd0z2Gyi51ibhIOQid S/KQXVU32KRsNT2h8+hsO9vYfY4Tq7vlwqu2b44vvnt78fotI1QOffPNef+7 b54Pv/P6zcmrt0//OvDN2cnxc4woGP4W/U1vX5yeX9zx9cvvX1yc+u8XxZaE G47gd49eWHJXnNsXWLKq8SCmLDmwFrVwkDYwyzkAf4Wke3GT98FrHu6ybfzW +ms2DFKDhhAiZ58FIYFhZIAOQdQJ5vBEGFaWCCbM5e50MEQD0+NmzrKQB/Ep uWBxJmHJMbi3juhFK+oaqsqU+DyFUTMBdnfr9NX3L5+enJ2zbcV2x1tXyNyE aW7pUsDKOGXfA1k0mnmYdHP7GPnE0OTayq24OQyWt2NnjWZ1jBLmxWlDXYnj Z7vsjd4kUBuui2xYDhdLTlOt32J2BlyCb9t7pGFhbk0Gi7hOyNo7bC4S3VRN 5PhCtEBmbkW4MbKnY2ZO67g3J+JAZwV7IMQLoEHfwUeDfqdg9fapZ0QpG4nJ p7bkD21MUBbI0l4ONTfupazBJC7r9du2l3VCmmBM5DkfXw6jf1+8FZ9a5bxr fk3YbQbPkZ1TXGcz1SMolrWhDAp7BnNPgr/Mf5qMKC+Fo+PFaMpUY35pCpcQ 3xk0Ts/Dx4+PuCtMeQhG4WWeUXD6ZYnpyVnZkjN6VtUoYFflvGHfEHTQmesk OUEQGXxaZBNVqu3dsA4Ma7GhS/dpWtnGd6jM1sTik/maGTtfhxAvnqwJ4m3A SVhvWteshf7TzYlBwy74mIcjabei4cPBv8o2KCUORSo8/f7FH88vji/uwThk ru7cIj2gJdU+2cVkdcqZ2vEmXGEiadrjIskHuciwPYH5ShLxlS60yH8zPhOh H34ku1EG80nMpsdrpkgWxGpe0vXGw1CuMhwiQJ9QYFQQrom6Onl39+ZbU+J5 yajPqeAbDIZORpTVlElstH1XYqyld9xT7KV9vSnmyYiCpYu5fXiJH3Icl/sU BIrrZMS5bnzU7avp8h3nSATd1BtdmIDtaX40OA6IT8BW2wMUxJyMNCUF/ghT 5a8opPk2/mrGX/EKiVgVPcAeDb8W4uPw5jpyleobg/khYZyWGuJic/yX3dQP +Sisc17COgesLSJ9+xYDdnEjLHA3bIXlR46evzz9NgV1FCEC6BrqpH/yA5zg 6DlbCO+A5bahdiPDZET/ee+BtyBKfkvifvc6EO5l1sEt94i9M0470Ql9To7A ruXlMtdk3wUD9vbkYY84GOJAhCEg03DRM+HeQlYfs//A9KsFOU45d9LCyspK 1lm2aJ3V0HorARnY7IgZMF5bFk/BveE27NJWEZSXd82r6BAxeFpeksCHlcqL 747/3E3F/j+RRvftyQV685/CwvuPz4c//ub827PXf/7m/PnxxfHQ5y9efzv0 8dkFK4ldenn2+vtXF+eiFTpt8E5FMFZq4B24OX1qedXFFAFd4Zuq7ozr5PXL k4uzvyIjiJKrVu8WzPs655YMPbytEZ30UB3wpr/MqxVdXa5f+H+ZbrfL+S0o f8UsvVxW02z5c/olgmtEPu9bfGLwHIsAnnpU5cWmRgtYwvfirQGxQAvMMsWS 1oV27uOFOSwZjrPp/i3IX/aHxRb8SlhghP/1iJCZHv0qHfzuQ/hf+08e7j+0 +i8Pnxz+bv/g4MmjR5/xv36LH8T/Qpp7FIF/Yaj5Mrtlfj5gOOnhYB13+Ys6 3BBHiMJ3NeY3Tl5H2zF+nSyrSwrluq6WG0QQ7DeIt63CXmI4C7YBAmkm6DuM NIJw5+gXCn8SyrlFTcvnk+R7y74TAyUdOGR0EzqCX+4C+3TmqG4LdG9PG4LB 1txx7FjjE0UN8VkOeTRS5kZurBpJnRdkbW9yvCPbPHhY/dsIm9jromgnlg0g i2agX4Q75CHBMquSYEIhQVuKHKrZyhqEEdSabGCpaGV8NYIf96ayfoaxGo0/ 5AOgDbIjiYBgkBG2DAvQsAMuSWNMAafkh5YUZ2TLNzm6WFltIRWCLd3YI4o+ ilOUjtCNrXu5y50mZtKw/VvY3wXZWO1KVeN8byOjycF6ddY6XuOdEPPORpdm R26nAHEbK5rd52k/Z7hDpZq1og1xsa21QFbUK3Zii4PZqQLo3NtrSNzi1qOx BIuR695Cmml05tpGkgU5e1k0qyS7zoolycmamY6zYq0sNEj2z6B7FyVmyjQS 4JV4RwhvCs/GwXMq/gSd8yVfyi4FiLJyivb2w1OKTd5o/7jOoeGr4vJK4wol ewOPKt735P6S2ZPw8ezN9ywmsRFXdLkOQh7IxHSYaDduBmIDcbfyrMao3g3q KC+rehsFZHOksZGhcRWXZDIh5Y/aNjECEZKENlB+3rhz6XnQiCzseYYexbQw mxLSfjpA+9SYCqUMDjMTn1hbDR1pSY9qJRM8zBhGRDYbWMoCGQLyHm0KZ6rB kjqCxE4fW740erJBx20pZh1Jw2PadxB0DHCTSUaMPCWwHJSWR7+H6jAyzGxB OCDprM6aq7GyCFpPbIxCSVEwb/MeXiLi52JgJMHpoCVhAE2Emg3bMnTjxEtt u0EKr8sLMlhITn26ongAF+2Mtlf20RHCRuQ/eQj8lOZJR1ZTZscKCGYYHhjB Guf2SwjQtrHfwRHVGpEQuNd78bqDSvjBS2dXrMlep+11jpJDVkZZS7gpbD+I 8VkG3nav8eZQh93zGC60Bj3yGoDjMwH4aqaUFLrM4pw4ggog7kga0tCBX7S5 +sahFa5QEl7DNf4bBXhAw2vmiJJ1rxkP1EJvIYU1wjxFsuLhmQwTafp4mwoP L8WBkLihOmGnOwFJhehJLfngcpK8Eq8gXr4SQE/xzBoVrONovk5ac6Wqi0NB ZHBEvYwIt5/9CHa4u3KDksswEA72tYGN/Z5qJEn6AVBnnY6+//70uawj/kpX VKuBAzndI70ZymhQeHQn+ypfrlFGRu6zKZorcpZ2BieeREqIJSqo+WyCvK63 WEb4uBRQRvs9h1viADF9JI2W1m5vervHe4kEI1DshvZFRNQzGmDA/03VgwNW ZC40GUnEEocS2Ke4LqbVzjerNZ1hzlCcIYouZgzQKtCdOK/YCTRjJCn0AzAq 2YbgvOB93L1Oa5qoAp8pVhl9XDMMxWoVCnatsnfYAUyyYDt7b6ao4rx+c3J2 jArO+a+G9Nte5T3+i3LS7Z767O/w5QeboAz4JVpTYNg85jOMFfFVClhQ44Uv MaQLE4mkupW42NlcpGY1A2nFuYmYt1bg+K5xo4tibr2Nezynb98In2TzFZwa /5Fu8Hhgd38DjPT/yj9k//nyAezcO9ybyZe/Qh8fsP8cHB7uk/3n6OHh48f4 +cHhk/0nn+0/v8UP2n9089MvgxHIPvtxD+G08bIp0P3vIxeZAzi0d30p+YGq YTArTCaTSfpTz2LkH5ec+OD5IqsqMFaqUSKGU7imkHHJFZUScGhWt2wSml3l IpLU+Tor6iEQbfybRL6/VRtUaDhFP0j38LLEhTd0XfC13XYYJ5vBFyAv4Tpk CNbRVNFsGrTO32JoaGtRu+RKwk/I4LsRyQMuU7yzb/Cet0lwKIQg581uxTsc T2acUBY9zxTkpFV2yWhdGEOxWbe9x/UOQf7K3XTuy7fSGnFU5u0EDUL2igd5 O3uAputpOsD2dWvGZuGeRibs2J5tvY8Hu/5Xn4f/bj/C/+3e/TUugA/w/4eP jqz+x5Ojx/DcwcODo8/2/9/kR+z/InR9GXkB5EOsAsIhDOa1bQa5Uu8+sDbw QkCjcL7cJD+l8gcVLyItK3z2PX62wUiQn/A3QTP+J3+50FuF4kIHLpTQ36bJ Gy9av51PieNpQhVwW4nbUAdqZ27RzYG8+jkNxQXl0pWQzwfwE0HTxUEUCK5K ijTlXWxKvkS82sRGlY7kSxkXO9Gos9KylMM4MX03GDS749fhdVwy6GB4n2GV inkiATo+2dcvmTMZGhwFK0WsXYjnGnY1OSkZ2KSbxWxVp7oFHKPaVIkmc4jG iKA01KDCBPLmnxtIcJQMoNoW3oFieFVM7HmsiGdJDDzTRvSEepa6L0xV+XFv rg+JP2PXjelvNnE0DaBqf0jWVDaXpCMRNPRvWQxcZ86cSCiFiWLCGt/uMnlT Y2ma1qUauqnSmXGPb+5+nCwSI7NfgGjCFoz09LlaMKzzUzyXQHzUxY7BzHc7 p6BrEAz4j0knppk/tvooGcI+NgQyh+V0shkRKUaTfk15K8oEikZRtSmLJHp8 HB9vctO3NWjjFEzEIEhrWgS0THJBvRXKZ5d5zyfGg1YYU0TU9OSfinE+3flx xssL/zdLdiS7k9Ky3MzDsn0Py4acK6waLXwv9kzXDp9FsB80j6D9kZ5eVtU7 WIbiHZ+Dr9Kd2cH09/NH2eHe4uDx4d7BwWyx93sQPffgLt3PFrMnj+HzHUGK EtaJRhVBoqbDXBZLg/emlWv620q9G9oIPIMf3N2sRIvlcdv2aUbJQtRuP6cn rry4xSyhARiN5pUIVLcf90aKeYu9DlknW5pgDFdKSvi1hAPK5krooFSr60q0 fUtFx5QRePN4gF3+1jXcfs6Pk/8Qfupfof8fPXz8WOS/R4eHjw9J/3/8Wf77 TX5U/sPN74p/9BlIf8xYDfFqTYpzFenYg6Ifvq+SXzZfrq+DnFciVwHhxUJT f7JrdotcR43RSBQqf00Q5hhO0omdNcC/4Upa9Cpm6jTkewj+p6QbfDtOXWgB Yx01iYucVDEm1I1E91icx6BASIhp0qi7almEFKglG/sbKpHWDbxGyeErDmI8 Y11cBKudr9IfdtgCIrhNkwlCNMgfOz/B1cFf877xtwyzpOCP31VL867W73jq oIsvs5mJgqdnWxpJd9i0scPgTgxaZ+uimHWCv/vOI710IOv2KJmZvyeQcZCU 0M9105fxvvDlIUC0k8JYQyJpxshEGBO47tWgGm9JfWAExaSDCoWpDTWnJri6 vT4yQcNM3jmZbI4DIGnP2dMFIEszLFfFpZQnWyyIIqa3SZY+f3n85tQHEmJM E39IbmaOsNYEVb1uOeWj5o1D57n1TfgvVckdhKpOYVsYxa5JZJYhrVhCLnRC YSU3hPENe3WPYRGjSPhBiwLRCdsg9T0GUEJXZUOE1URScX9PeSQtRTqc0iFJ DyaHhdRUK4Xsdv49FQrbYeKHRw23m0DcJR9Hz+aE2JME6Uu2RoxJJ8cwxIiK B4ymdQeJT6jzC0VwV7g0yYz0C37dWXAva6KS6LjnzsDKUO3tccQ9OVq88ePX hEWjzsLczeyZ9zxakanSU/HwYvzbLE+lMh4NayyaK3UISkatZfnUdymiYC8T wUekE42ICp9pQL6EV2wEaZCdqOKVVxJZbyORwXXAMKigsY48ntiuDcuzeHWI yysJHvxJ+uco7k23TRLTTzlPAzTo5WZViviN4iyLzNpLRqWWQv8PbFxudtfJ +RWiMMPRnFLppsDFBE7aKgN0+J3DBTn+NjG/ZSeDa/Ao2L5076TouME9kV0C He+kI7l2ssvoXrI/d3aRdvVgYklWTteXY3mM0QcV54O4M0DrxnKIcOuwtFib WW0TXX/k20VT/2cTyX/THyf/k2X+t7f/Hjx8ZPHfj/aPHj8h++/hwWf5/7f4 Ufmf3TIdBYA/JPsv/tKN8A5OqkHxn15S+b/gMNoKVAD0B/6gQcLw6bT7aRP0 BKcyLMlSVF1i6t+nGod5SPTfxnBNelqCxG9L7SqNMLQI2nojBQY0eLMWuNCs qUq2QC6L/DpUDvWhjhSLFvn31nU1XQYcaWcmYuxuGKsYMn0NVeGAsgaaIzuW a8XVXVZRD+5djq1X28eQUSZAOHi7KetTM0L5b/yoxpHVmDaBytKknalYaK2s IMbGlmqgJk9mxrV2NBaTJZR8ttFyHbH3cJK8xmW/KRpQ0Zr1Riz4vJCKpcKC JF0LSU8/+KA12eU8p84y7GxDO3CtwPU1ZCFm8DYQ769QLVxTuSDyl7CRGiOr ko6TISQTUqQrB0mWIXBd4NVMAlyikZYOw040FdteQmvvK1AocJBNGk3PAqMj BYuYIKrGv9EIQWG4s4RQ6tsTBIW5Y1mWJgixW55Dkfw9zFmJgh+Tz30Ikk87 wb7CzjXdnaOj2ORMA5Qh6PHCAh2cx49YSVNuZQXKNwU8r7A4k0RsYQY6VnL+ G8ZHUdBxDxXcJ+FfOMGzUxscKBmEyBvG6gnx8pLEFjOSzGYjFD0OYeKSrMqk pWPGYhbFDDVRwt7Jg+6MEqW2wgqzkyVtGVWe5Ma/1rhvXYlbMsuLIsdcLoNP JWMgNq5EkrehEeCrFkZOkHWwZ56aixSR0qqdgUFNc1CYEcbLctddRWNClwDZ E37jxEJS0RHWb6xFu9wmSPCoZpyIetcvck2qk2bOhkFOYZDTjxvkrA+WRl6n M2zoHiP2JeWpyp61y5YcDRyFbpnpch8hETZLdzi53Q+Bv96ZJM/Ip0iOKy1k SneFABPkDRecdn+bfi5JJ2YmhFO/q4jxnRqEWoYim1F4fNFc5T40VWzpyDe+ QI1AHJ3O5/gG1AJEO+DD0gqALJD1fDOTeNH4gpewZ7yo4ZjqJq0YZKNXV7B7 O5dJUboLunebyR5x1Iq5jjhtayCmJSE+8r53w5QpWtpyqjg+vY0XpBfRGge+ VxQA22lxzPwgC7WD5GO0jjAIXj80Nq7qK9kEWpcmbmiSvKq0HLoOEXeWKoKS f1eDj/w7DqFu4I4lRoge1LE1CaubuBPQSm5Pg1YzZEmgWZZichPvOS91KBnh akLCcQ6bYWjlnVwbKksn48ArYXN5NfZ7WDQUaU/3zLVgX2tqG4qZp8ffvnp9 fnH67Hy4A00KWd7qCo15sXLeRmLmCbutmaI7dkZxZIoJWGU+BCjh0WeCN+Uj McTEOzggCmzj5KXRFQGRl2I03xVTmj9MfNeQ0MvpoJxxJVYgCt0TFMFonE/j x2lEwZQa0lyCXYHY1YAMQM5jdIkub52MJzl7gXsn0n2DGVPBqjUv0DDRtMXM sQy8/Gk/XWlQrT67weRwwr/FA6l11iIQm64rU66Inexy8RZTExCDBK0caA6b iZi7k67okkuzS/g347nTs8QjGRZhS+qE5gosBvJCkCKyBEMpyi9QJGhnVx0D m++BEuvyvDNmcrvDkt1jyPooZWCIEfEXHPVQ8wsYznxbJ9FMCk72v888OiBY v+b6C4aSjuZ+E8EFuPdkaLV+63lIpx+ajHqLsgcoP+Xv11zMoYB20/30ssIJ FqEohZNdXPYXAb0AL05GvSnx82N5e8t4dl3ZC8ujs8wvDOlFzMQrjATZHZss ZA8EdD28s5jNQBtSeqXS2nj6jbAIzqi6XecfXg3CS9qU70pUEXhNbu8/4q3t R83iTaEddtous5ntKpDGiEvgMZ+DXSYnAZf2bQWOzffJVYGJ7lZFw5TDEj8S JJBvie6KEdpl0Dnw/n26A4tMYFBMzZ64S4EWw1fZVjKFi9B14TCMDAqVtDGX I+5Hp75LkN3vRX//SurYMtat1IHq3R4FpH8sncQ93U0nQ738PIpppm8Xc3MB dNlbJ1Ob+AzLe/wGVxSGwSncWUiB3Mq+hpjW4BWOQ6vVK3O/sYX10fd+7REW 226G4ST3gPT4KQPzjdw9Khr6/dbsZ4xn6wJ9OIrrA6lkIZarvDNL4b+SM8n7 f6r17b8g/utg/2j/ieV/PTl4iP6f/YPP8V+/yY/5fzDbt+v+wc/Q+4P/tpyW JMVw7xv9T6ZudfbMu7H/1SV7cppqUyO8Bqqk7QFnj/Efh9uzx6x5yeHtu3EQ IK+kShlUvo9bJFlBcUpCcq2cZl85koJIRjq4XXOycDi/+FYUpjrEBJH1vVL8 hAiNtIv97CDoubahQluz6Hvrhx/WJJlLKoJ2gv1jVMYiGlFoRZ4fg3xPW6k6 LU9swPclxYorSc7n9ydc3cFG4f1BxJ5lFQLUE4fQYbwE+RDITmBOEIE6/OAg FHmfHCCps2eEIl9UhGEc0wS93djDvNRxCE+oqsKRL01c5oLgNOOl8ls3ZNjq LB5TZNKxxRlhYCo7XIFob5LSwcExwLXatLxjEsoHD4zFRyy6XMbIfXJxpfXf muxajC3TnGBsonWD4wASFqY+RhgLziClUAHQfNyP4wSS6IAUmNUGQ5IrZg/Z /rm2Xeg4rvprfhOk1+ArdI6pcfAaaq5LEn2Np6Ou/iGAl+rO8geelOx/0NW/ G7kUKb4oRLDZ66NmN71xUEXmI3apl/2pGZ1mSwXw6O8hRavepjfZ7SSlEFE0 vo74qO12sHIKV/iSvUIK/OOe89UvoS2/NnyqOV6V+tlwPojvZRDcgnEmiOSn lRRdrpZc1Tw2FoeIPtrJrEkMz4zBLWZRIlR8eKu6K6096Nqtg4NPKcXyDvqW a9y2QMHJEB5GAL6QcK8OQAa5RYT0+ztMoWq+CBQVtSEUjRyOeS1Wc67FE/yP Cbp3ZmYN7bZIA10jJEs2B8J9QtZ6yVAG7oRKXlbmmrtG1xn3OxlkhXiXuDgw bpe0NyIHJjWJOrDYM47q5RHMi5zydVzb7J3i5muMpK1bQ87oeNznyTMaCNp4 NxzbilXCsdDfbAlj2+27UsMmz+kixACBYjGwwV1iozuIvCsrNiDW0THxx2nU bBB+xvy5WvicNtw14tOzpmwu0Kppwx5f2XgtmfbajPWwsKs1civy8NttLOvP 8E08f1bnyTY9ABN2BScPLdSdl8O1qLl3NoRekld12Q0eMLOZIhGzlFbEAc/u KXziwXVWP2hX66BF4J3zF/pRX5yU5uq7TDw5aflUOSJIixUVKE6bdg4fJoz1 w+KchQ3QeSBMqcCzKQsPV4NRDEk2KUIcNrzxwYFTbIK10w++YTFWPEHpaXww +GQjIbpDz14y3quxCNQqjmVcFkU2ksAlydFKU84U+lhtSEQczUbQ8pEV8wKF 6gwybirqm4i0Yz4RkZhROC3KTc7Bo1sO9pj85TIak6F9iM2WffLDMLgD8r1r G1PKDK0jZD+bqtTcHL4u4/uiWK3yOfqAEN5QeVCHoTJitOCAUaGKOZ3zfYrM 8aPCoioe5IIWi++47ssHHNZza+cP6yAxib96fXFyrmBy1zHUhNSCwf0mNkOM gNGcVJocYlXIEUO5DQx66Rbd6np+qZgusEZ0LlJYEaedjtMbB4hExDcQw4Mv 79x5CSu3c9KherHDwnuMiZAiN5CUecvV1E0mxyWKowTotDxwLRGC25L8g9kS RCe4eKuaI3oUCo7K3LmBuVk+sMn5mSVYBbtzGTBiZiRdsmtxYQZo5P4sUSW+ JoqvbV2sQABvA2+XMnXYEox9KO0aZvOuGZshVevaAcHB1Vi3sIEMkhWfhrbJ lwumwmfHfzo5vjgfFkeHAL6YE4loGAybDnW2+wK5TX1cGOcHEFPC9evIdnw+ zdkasbVf1oYXhPv/7Dmav+aPs//xgv0KFsAP4n/sP1L739HjA4r/fnj42f73 m/yo/U9OS8cCKJ/+uAdXYoPJIakWQqnuaQC0FhYaqL1JtIjgHtXu4CoIw/Y9 fjuRzhuHAdjcNZIhs54TCKTVqwzrTeKdGZoasKOo/oRQlAxnzPYrjpWbdBrt l3JjTEPkdxJ/DQcOGqh5NldZPb9BmePs+PS5WuoS4sIqv9NNJDisdBuV2Rr4 v0o5YpXzK2qWSkld6xkpxVV6OxglnGhgForrnWtaTZ9qkOEpip3FVt2y5Xd9 nr/Fh2t11aYTz9k3307zRG04KA7gXjFgiZVYCGlPVExsSfo0y6xVeUkgklRz MxMc9J7jKJFCiNVNHkH4jqk3lt4t8G+5ZAERSQe7IaEt4c/ZyKnVgDp05N4h QRKGB5vQMpbuOFF4ZP6WcMd9hmqde6hdJjuMiBScE9UpabJVpxZ71wQmujKF j95kRavJ3J0RC+2W/D5vY4j/w2RPwaMluidoOJJbsUg4iLSdcEkxg/uCZniA 2C5oiDpNW1ABTKZZmRvKbhQrQJaXCwdr7Gt18CMYjCn40d2YN50Jq3WI+lGm UUVuPVU+Yq9DvRui3r97IOZNuSccboBzEFX5KixtFXQu2kB/sjxdpwYazTvl 0tK5N7QebUr9zjqLSZiH/7qUDE06f1x7BeeiRxnZzLLIfSFN5dpelTk2ZTVT ouqcV6kozHEPMfjrJoDPJGJs7FkYFb5fVR8tNbixAOJ1TUnGCg4/zQ22WzkV mtthemXFgCUOr7QXkF/Us82KcpaFezSbIQE0wq9bXq8GIEH+U0uPTv5j4fi3 l/+egLhn/t/DJ+T/ffi5/stv86Pyn2hGHfmPPx0HoF6QBPP3a7GF3EP8Ez1d vL7zYlnW7/8U3MDPyfuLjjb7iISZutV6drHHOP6IbHir7P161oYPCdRrBZJa +OgsvNqTPae1DhXnl/Qb6b0xLKnKRHlx1MzEpeE/LJv+qiJcN31hWITD8W+R 4PB9m4wPARgQcjYlunc29VQlHXJrUpUKcj8mDPYNC2TVQSgYNfgl2NoKM2OD QJDaaX/YSVtcZ0vi3Fhh9rp652xOsg9xLZpS08gpkw9GONs0kvUCl+bukMfi NN0Bek3/iUSKSCpIPQMpg1HZl/6SBA8Gra/6r7vE30Vt6DfN1XlvSi3Yzsgs CIMyTip1XH7oNbH/NVIDwRLd4sWam0374irU/wHCrnMt8NpNavKJZTn6jDDi sb3qh8ZJ8QWiOJP70V40kOSiMr2pBzhM7qNOhT38ATHaYCVKjDF1gyikpMGN 1PChsIPSZT6OipJKU3VXjOtL/oAiz1dpJ52NYhm18F4+/8lTypIo5cUdlOKr rHyQUMZJc1Vvyndjjv64pkVypPPibtLxfaE4S+idetK75FMsjBI+bsvtWY4G itbXhMuuiVqjKih4pBPKPaI9Z7QPh7rjrNOu7geuR2lJV7TnpQq37xNdDyWa M0qZHVuZLhXDG1kUG3xVB2MmegVbKnTCmUYxbXDlwFBdawt50D11LpE47G43 JEFaEbjAitVmhabiGVY6uKT14WCNfpVOoicFVrTITPJfUhTyR56lvUIu0HCS /Dkqu5RcVlbOtmcsKXQx0dXQsxxg+cccs7nCzoourDcdxVxKbIrYzRG5Be3x 0C2eC4zdmc02dTPxZ6+ms3d2x9nrGbI/llWf3X3e+u13+TW9LPYCZNXJfV67 H7+uP4lfd3bHnAJlLnVIUH8LtVoGnAGaficDcZevabyOklq3L3T26Yy1IoZI QV3OtreCX1R67QEaAh5wja2Ei1KRMAJSab5s8oBPjuJauith+Kqik+Mc3ShI V7Ru3nehIhB+gd4ntJywEYV61lbJCZfuxTnsAbMSD7JUCBWntL8P/8TgrHwf aratK/NGMPEWW7dNBKR0VpR86nB4kaf9KY1kpOAWW3EKXMupn0QFsJt/k/ol 3ERcc7FJgvQ3T0dHIflU1N4E3iNA/l2f1tlGwBDU1x31HscccPKeIU/Re5qE WpChnnJJhD+XamF17iu6S1nijIF0pWISCnBvzo6fXZw+O36Rfn9+EkFZGPAE co/1LVsHxexDfFbAu7rQCeg2RjGBPFoYqE7FVHCRI+yGsWTMW0kAqpFcV1jv ioXfhLuhrBgSW3kgtO21YbIhEJ/cm8AxljmWrkcnMUbRkTSTdIpnmhA9SY/n wVu+lrrSvP0UO+PLIGHMH5lx4v1Xu/T98FCJQv7LWkX++/w4+09R/SrR/x+y /zw8fPhY7T9Hh0ePEP8f/vlc/+U3+VH7T1F1bT8FWXvm+XTDbOX0wWuyQtw/ +L+oAvrrN4tVfda074NVBuXNdLaax9hPlIeK0ZgfRoQtqkRSxmGIl3xvV0vK FDdDtoI0U1AHPFysSKEQDHzlmBEsvM6zST2ENEo5dXZD0xZ+qYEWrApQTBC/ V5Sz5WYuJcJLie2upteE6YJxTQ/IRfNgRcCbVsEr4bpkZbGGwVhcekMhXHzB Uk0af3vhaEizbkgNoWBGLIfLV0AAFGQYnmBk4fxKgs8DMaqd9U0g6cFkv5BY wRmicqzmO27hBZzDTPMMtQEzoXqrGIg1cgGDuxQd2rgEh6pMOBCNyzEQ5mb6 UtIWlT7C49ILidws59oAKBKNgT7o8qP6n7Nc8S9bjZzUukEsb7lIyDXMDr8M uO36KNnbcFPgg9Va4GwbrAMXha0046hOreqvRoNF5VWqb9g+YsTNCBwFQZOk WJ0Y93SEIkFxWfqgWMswDamxGPdSF5QjitCKFJ3PyxIVTuDAW+uRhWgXlc7F F0iqdu/Vyes1waryWxZtjxkdBRdYdU+/T07er7E+BQ5vkj5HHbFGeo82ik5D VBi41SmFc6TPI8W3ORfrENnX0zAokdcFYj8GP7j4Y7VYXjo6tCreDqmVjH5c Phe7cJZIrbQdkSUHUr1+9ezkzYVnbZi1IziiLruR+mX/JJXX4OrEgprdCMKa KvC2kPRaAJH1/acjngE+BoyMNObYWhpDs0lLwEFIlHP2U3dqpf9pXb1DBWHN eGNc/VNLQJ9zUUa3e8Y9uThjj2vuEXMbswN6nGBA/HiYFQHLCZvGgJ9dCmZ6 THs80a1oPjdQbkNTg0HIYo+1+iKVLcPEcPxlU9rXi+Wm4aJm0XBCPlY0eQOu za6Ly1BGGCTy9TIjv2gXIazOZciapWGkMTaCCEZyd9CToIAIb+DRvWR0cRkU aejC/K9zRXjG+qGT9PvGSpngB1b2ZqG5cKKncpaSNRrqftF+Pnv98uXxq+fO JE4r/AMwzFfwv592kucy+8yAhOlyis+AJ+C0Ac1zdiVRO2YFSLRsib3qLDz0 2Q8/IO/MZvNF3bRn6U/ItDPCH4dhPFtWUu8nqn/Ci4uvh0SwKJCbZA1oJZEI VsbyRUsALopdP2Pd5YaqtxUMJhNww6VPNhNgrFQoJIPPOyQrwsvFe/XN83Sf rtn9yVGhF0PGhvMtl4AY1+R8o27OdhZmGwJd5m4E3XM4V45PZwmvB2P9cvrU 6PXb4zdvTl4990kOc3mQaoNKBgHQBDz7/PTs5NnFbnTFdPPt0nDJYBJ3dMdg G8/OTo6jJmrpLiR1wVNnz1+/evFX/1jjRuUTbmRoIIE+242sTlokhkidL4XX by/Ovo+fO0sQAd8NX65XKQWtsq4UUMZmuOqIK5Pur1KB00dBDAQyPLzPGZGJ +6uSgJxIY3IUwk/MkKCHyNrOx5g6UQGWwCTsO+xYaXIEA0QDANvMwpxnfgzc XWcQcPLWlCL0g2LfkW0RDhx9ck1ncEdQnTmzcic5o0whWDqyESP40G0rtRj8 ySMjJLZmVy6Ja2TMU9jou0/LNOkEdGhNm9A23WkcldUKSiXNB6UCi0DTzCE4 30XLoqUKcq6lJj3a//1jnkwEomg4bF2/KGcHSYyU5DKAGnJrrZtiMNMoJF4q zfnksVKY+GrNKWIREdV+A2mjhjaQY8F+EIhFIg7dwLn8izAXzbtibV9MxZJu H5zjBzmBOQzt+Z852e2X2XTcAH5dI960ahm5eggcE4ugYY2IUrFjycbtimIz J5ZiB2LU/QA9Fcp9yZOFGJtOQPfeSg1TkpwUdcejD7GTO+dYKSXaNo6PjrvK JQdOWVJZQs/4AFLUY3xODA0yuiqJPTZROpcDAbvlhERyZMBuJ7YJZEoNFZ+1 VV0+s7SSFJ75kmzT5KMOH9PiL3f6znvdj+p8nTN8/4IA44VMaBxJ5BPwm8YD KzQrYmXpJ5msbzQuPthR++ay3H8/m/P/TQSC77mO9yY6r9TlwIElLM0ftF6O nD+q9vCeRR3nTOgX5Bm8KSZprwy4R+3UkltrDGpeUB4zRw/C5T0j+Sdy5cAY xfdOQzuTCImfSCrkdYglw3L+gIROC4tdkxsF/Rg+JiDsjOoJ5aWzmruZibYU AQLoLT5Y7AUvcnQaopSMWqC4VMzFmAgcmoupwfpjeIZYVdzSOezw03REgRyd u0ilMBb7Bba08ghVxP53DZHS52+yTUuHIvCdfDaBYRRtvHAJhT1rjmvWukmM LB2sB6ZgDyXSqIT1hnZDVBJtqku49vi7fCYpSoFRUKtQ14gZGtdBaeDQFO/R xfQOBJdxCjrXVAxPdOg9JVBOFyVzWYKhr6cScQEEy0NyadbhztonQ05j0QZR eRNhgLhwKBtjWWbSUm69Ui3gC+ZdDyDnIAi+PX397O3xixevn52/eaB/f3N2 cnL+xseJO3sDW6b04M3aZTp6GB07iiuQeYjTjeJ84a85Vo0GkUBkBfJ9USVu twL8aGcBjNVou31es8jm1xg19EOqPvQG/vsDywb/JL6D/70ZuPTxjP+UvCYI 25YrZgvwvOQsoGgsF+oVMSy13hm6BpuNQX/ParvTDPFMbLDIXBs1igRWzHJG sA5yMqo4R0HEIhOdTM7U5dEP//aTxHuRXsiYrngHS31W0qfLqtv6JKH6LvCF 0wfx3Tevz0//8vab4+d/evvq9dnL4xfUJXveMA4ET4j5svHmzBB9cfcDcgiP i24mH9/OpgyUPi6xAE2h+Z5oftkQLunIjQfUpotXJyfPYcpey+GCNXbpWpsV 2ks1yZCQjYmRjeIZnnx/ftJpsE54x1wCDfUAw4NVnGOOKzlNfUtnx6+ev365 a5UK8rYJq4Mt4JmMRJqtfbCtFy1oA/2cn/zH9yevLk6PX+xqfcp5tZkuDSW/ szExmVn3NwkTUjdXJVpJDJqwvfGD+PPpixe6ETIIOC2zXEvYceSPjaEnNCyw G9Rzk2eYY0I8xD4jUQrBpdGOZWP/AgXvPUYXFvlG8pSkyW5z/aYyysLgNiQc M+OMkqilxrMZbrbHZOAmvCbe1NEZjoW54t43eX1NtSSsFFO499cim4pxr8+J z07O//SzOK8MdFNuG+o3yF5tmPcYW6pj+/4Vjy752aOzUrc6up3kwgwbXbNX KlFPzG9lNiH/eWGNwaZ7BL+8nIsFC3XFpp6JuoiXwEJsfj8MXgX3vAlUrEHi egesHavwYk6JIGom7U0lEBYCAl3VjXh7ukKthkV7MAXWyEJeSwQfy4rhgPC2 SAkGBq4NsgTqxwWGEpE59OXJy9dnf01foons+Ra76IrFdl4juUPrm/dbb87+ lYJnCFtBQesm3lNzHqQSRkhYYSlu6JJUPBDgZtYUyjevkkYloE4jLDDfVJ3b M6zVSNX4rp2UZ8HiCdY/5tmgR4LT8kQNcQhYcFLK4GLFRoO1e11XrYSRkT9L UN+ZZKVEzmqKCBQSrffm7PUFHPbj57ZDNXZOH//57PTixD6/ScVNQt+d/OXk mX31Pg2312rl2RctfdcKtyJnQfI9/rezmpFbx70Qtcmv9wWvlZnVFnS4VM+r 8d+dLgeiA3bMdzUXB7mkqDDF8hgc0jgNRneyILG9EuVf0fnLOQheqpyAupJn q3QUQqyvLVNsoWVtBNQXCSPEG2Y2MKxgpyqVu5oRAzcyNThiCuYwdnJ7PxaF Ldmb6AbEQpY3MOjGRzMlRnhOEaxNESxdmDnJjkj7viBEIygObI8rFDYCPTfX oY4puWLECTAO/SycwmnvtJVdmjUVZMqxZoquKh9vbde/1LPF9KgrMvmttpj8 VsHkVw/Z77Zw8HMEUCC4ZaxVSdYboSgu0sNMAemDzHo2Nm8akYpRZg354i9f IEobm2RkXZaBGzgdneIzpJgAl2WXkPVOfalzjXXlOr48wEaGfl8C1OPlqC/5 ROpLP4L6dBcjQ9BqmyFoRWIZG255FzNR0bZuodphYY05mZScQIT0AxSFAoUg +8WSLO/FCMMyYb3q6ESZOmSP7wqpFjWtCD4nyTqGCtUgbFhTRSyoKKlEBcor /opNGg2P3kxlxzyqt5wKHroK21y9U5JAeSjJ1qFQoodBF2azK1sThaAhiVeo jnbduZWWtzbYhqSEbPjLzN8rkVi8GhaLd1ZO92ZlO2jgrHJv2eSXvLMN2+to RqH6ENnPJPqajDGDIsAvokN/QC1++auoxY4QRFUVzWvket2i/JquKpoprZ+j Nd/EJ+uoTiO9q/1fWTeNz8uQcvryl1BOV4iACfziOYgXjQsBEE5TM4055mOJ /sGYSmHpdT5OuubrroTF8WkX352cdcVvzia5XyjCYPAIH4hYg0Lcj/jY0MAZ u/JyUzRXFjGUEIgfGZJsb9axcw7H1xUu4ai1ycn7oh2ME/u7b4Ae7bwPEniD hcpFJ+P8l3/Sb8/tt8x+u2ar/AtcGjK2zhUUnqMAO7ziv5SNXRNCMFJ0TRkg ddPqKMdRLBxXa4ArYIVwEkQzSSHBlwE3q64ayR1JKVOjCZsCcsv2TWGm/r/S B8iOiqw5nrdvyvxkcS5RLJxY9dHbcxH2JtPCyc8t7i0GYpB6R6RiTUEYYCFe SVxLWyAgaLLM0f5qGpsfzahbzVGNFwYkslku6Rzu0sJbhN11kQ3FJQXjFIPo nCvY0FIgTUntDqgxvdSzji7EfPJ1L9gwDyGKAiVEF14TxxLyUIBZ3YDqN+e+ uD57E8w9Ws6cgTJcxtPP6hUkg6L8G94kSCktlfgByjjlzwQWk2uDdsBaqinZ p6JULxULsjaU/GaC5SJXeDPnNV3wJTs/mhAB1SrY96WrLmtxULgmymc5GLZF wggJKT97HeALKqOFC2GlQmAtvs1bdSqiaGTRE2ag6yW7DVgNvz1BY8L50xd/ PE8Z044+Pncfe8wfKX33496Pe5GWIuisnNKU17OCfWAbB+Gtm/AzF+Qsba42 LVUQVd6y4PX4piLo/Pg8oE9cnyelHmepWW4a98ibWF3u/vyxtVlr45Kr5lyw mHzIHF2X9gLanB2AuG7MX44vLs4ig25Hju1fStfDlxK+lFEA12iJuVRsqwCx boUfJvwhe6bZJ5TO3NOsgu5yDZ02IxlHY4blHDi1Dme0aD48a0yiGpj3N+ff nrx+eXJx9tdkYOYeZMfQHiKBxSr56pZgylgZNmW2lm15GiKQmJIlSnDNcQUa 0iivM9PnKJJmnPCfgrIb8hhZtppmTc51B0T2wnYQ3oyvUo7BIPajDJybG+Td dyoD68Td+YSKuiowEFmatQgrfkCA0ENZhM1azWAu25LNB5JxXhEEaFSDEaMi QDuEB7ERJ4TPEud56aIhcRkZXQxZVJQQiukGdXWOtwilRn1oWVyV18T5UEAR pfFTelxy0l+hcOIlBN6ljOiIMjcnP5EAf0+cTbnVA3ymxoyETzS/pgeVFHmp 5CM99e5PPg76Qfy491NIciH1b3/Fz2vEP/+11lA/+dOCjz7nJUY/Lv8PrgIi rl88C/AD+E+P9g3/8+jhwZNHiP/0ZH//c/7fb/Gj+X+6+d0sQPscRB/+RaSG +6cBahNc10f0Ek7v44TrPWSpCg+60MBL+nBL6p81uQ7hcNvGdAfgku/+Q4BL IesaeHacOZ3EVX58IQM2LWzHTOJkEw+bJIU2uD79TSXV59lVwflFcvcWpXFh 26SA+MfFrlG7Ji1uIbWCVF+yVix5cpKcMvYhArawcOKAM3GuBSKllhSTnGMF eHoqOGIk4N6DUQw0oHKGRj+jj9gBcuAmEkANSp+UXEWqPiU+cslh9uPeVPW8 Id3dCS4WuegRPxNVatldXCxNoyWjFoP80NDYHNGadCd1MUJbiUrQHLVEMBls urgVL+oSjQVsH8CZcHk7l58mqU60OeSLECwUVRs8PqZ5H6Y57A8RV1gkSc9i 1UvLrFOhZiaEKoCYh9el4A+3gSIulnbgMRpuIy70Ut2d1XKe82MylUl67GoQ JCovWUTt+uq2oYOB2rvbUvKPsfWdMOnleUOg2Po4dhi6533CmHiVvxO02MuX aFwkaR021UO+soNhDYzB7QmllLIROZnnmLw7J6vF7RAYGMU6n7xvMbs1NWlZ Q4Hdpk1S0qSsXFOP/iPB8ZhhWz0sqITAKjA6TjXUiLGU1WcSy4/8aSd5puXZ qNqCUk2sDeon5LvXVyXcnlaccpk1BjrImCGE/blmOlgv8B+W5WH3xoGOWUOh s+N2rmhSCadMAnKytv48eV5JlZAZK5y3FOT4dfo3DObg1UaBMsIZQ+Npf72i atF4UkAsZvSPce/2sBNvy4+buylvilLcS1R8FjHtA+IJeka4rip0T+ObF5zt gA9j4Ook+V4sDgE/TLBLm1D3Pc7RvQikn3Xt/EukvYCtpeXYiNTY4lY1fsM1 BGfD9dY8OH+EkdanaNbIPpGg/z7Q4N83FcXqfVKDpZIFwkZx6ReYCawksyQk CKGQ+Aupcu17DY1W5JyMT7AGFF7l79HUI+QSf9vIXjOvQDLQu9UzbTEMdQ7Q qabZIMvnilI7yWugprpgasdZyi0oCn4lvmo9VlFS2xvj8cPX9P0gXD4jtXz+ 8fofkAjynd8c//fg4JHWfz06Ql0Q8X/3H3/W/36LH9X/ePO72p98ijVgpXhb 0K4GdT1+QWFfrgPaSymVXot/5Ig0ePY0/SF9l/4zncL/VvC/Syzy6mWTHUSF 2dmmAEo/vradprbTPRhQb8kNyQi0ZAiXlI8Q/NOJYZIUlJDbQtAxirlICPCX HFP6rlhW+gxJ4GOQjS+zkBJzWchfHrHvDKbNDHgq/64Qw5WC7S4TTZTBuCkO tEMwlS0y6XXyJ7YRYoqXlYpgIydlfsNcSGnUiExeGn/BvqokoSa16nxX1TK/ VSwFkp0LzIDnm5jNaJohzyUL8F6kwqEiC1KRb/Wi8wuZ4rT9q8n980/nx/F/ Lnr+L6j/A38Y/3/y+Ij5/2f8r9/kR/m/VLzv8H/5FPi/lVcNfhRSkIo99QEt 2JE6eC1wO3otFHgTgKoRI3814bJYSt1J0HS8nbBnItx2O0h3Nxyhpp2GYDed jGR7Bx8Xay5q+XOBRFyHT/1xHKbuzHzpK3V8hfgWiToi6BipzTHlKm8PJqJ5 BxcW1eu0ZEfkrWRvnBHADiU39SBbOTmcgczyeQzvqzUqbeWCC19C2iydkzxm CCsJ2yfAZgKD2a8KM4lQNSXcV/Flo/hZ2gBK6okDeLkAUB9tbH/y+0KfGIJZ zzWE0OARMiOCkcNbMTUHTRbwwI+LQ3zmx8WBRrGLxY+NZVcEg8JVHKWuE1cg 7oR5GDIpVVHkAAxCBC3KTLba63pLLq4Ko+7WV+0ijLpOvmgiTT24dD9Jz0/P BxdlKcswFqd+HMaD1nGO1ArVVTUXxxlpraq4C4B8UayKVkHfWRapmCANpYoA iIqlikNN3sLAQQM2+K9gLRG8N431YhsYqLbVUsJ6Mb4CA86KFk5KtSyC7/RU 8pfgWO8Mj0psz1UoJES/R75uObOT5KVDnktXAlDHMQGMPID+/vBF1MhEq552 7HGUsl0XFEOsZcOpmlSNqQnQ36a5lUJQ1bsmQUBDAZmRhzHeTs2wrqQtnxcr UB6q4U5DdUlm6Jz3f0soQFkMEya8sxAbvRYgxh3rlH68l5Uh6vNz0cX/636c /Fe3s/WvggD7Afnv8HBf8F8fHx4cPX6M8t8+PPZZ/vsNflT+w83vSn/0Gch+ eO4NC4syNiVqaFDWw7cSX8ynU8pnb52wqi8IOqToU7QjpnJuE+moVclmyRTL QRi7jMx5aMu+G1ixNrjM9Ioht/ESL2mQkjyq6Y0CyDGW4B6qBqEO4hGLVvbQ rqWcZlFZHryaI+CzZkiPx/sKF0FWyYFXeFAMhRnKMf6cTc027463YJ0g+p/U kfYvuyraBlhWcik/u7+qBc2YoWW29ewFX60cjv16ETTatxsGy5kPtsSl26kv XjOpAu7HlfQ952GIIcI7ALCD1ClRkdEy+fRUzoh20HbqF0ZgYMx8wM+K5q5+ 764Wd6fJ3VdnfqYxW+MBYg7FRSSjmoocziWNi6K6Ei0rAKsERM+y3YZLV2cD TeLeYPIHDOD785P02euzs+/5sFUOGMken6THDGQ3jkMG8RihOByXckKhDCQb 7OP5yZ9OXrx+c3J2niKOX5JJzCEH3KH3B521n8WAf+WPu//JV/drCAB33/9H h48On+j9/+jRPtV/Pvxs//ltfvT+Z0dtRwDgD3/ck9IQylP446p7wzaD4gA9 rPKAg393QO93I8LP5UFMgQjfnJ4p/it+8NNWRwF3T171TVssUV9cEGogBR5h JgzWYJlz3ZfrjHhXmpHpvVFDtnB+Ph8Ba3qtRV3jvoBdf/UhBHV+8l8Joi6B afcCUcfP/tUg6kxzMeA4BaH5TAVMPDZs/GyOF3nT1pxhH5JYxVyUHj9/efrq 9Pzi7PjitcsqDOWNMM/V5DjMC+vU6GX5k0cWaiAm4T5UTIFoiGHR5rxoSNgI 7Ee/iPsGFkaBPUKhXNvCuI6XjzPRdFLNjmt8epxhPM6L62K+yZZbyFHBCBiQ W0boZLsukc23Ell8VrKlAS7rC6Nmt1uZt5FaaT7BDtdDrZJ4IGWWsjS3PctE evHxs74RcIKSIbAMRzleDW9988n9NFGSiAKaIgWqYRGgueCr31RaPAttcZyI iHFJUdgfYenhZnd6o61mYpPwS4NT2TIjaIDYCcbw4cJu2FZYN1/ri2UUvKLi dyJGHzaUVf4kVTyuznqLlZcHp2Piv8Lyfsw5mnTqjWMrFWHHZUuqbOVqYISN DZ0ZyFISwP5bx7MJPjqA6fDYeADt7VrM9m75EtgtXDl+xpJSNwg1w7UL4y8u BYPmAfM9OtjxE2uEDGCYhAbjyvzotXRUuGEkYJcKVe1YVluOF4q0N8Ued7gI YOerwg1mx7SBwVZqAjLoQc2TVf9Xw5v/j+9fXxynr/90cvan05M/s8205AJm GNG7oas5L6+LuioDHvu7UOeKKi+WC6ymIAiBQkubqbBlWdGG7KaY2FU0K437 qyusWi6m1NDwJPkPbMRy/RRkkwIbHc0RWfC0HjiqxGBH8RqF6h39gd1kiHDI 512jYm8pZYljsAvKmq5aZERLNGYzVIkAavE1ikF3DpZME6mw6l06wgQsfvNB Uy1a/hWBR0tDvBz3jjOxGnoS1p0wAcjw0W5qKlKxWGg0BPHsjPV1ypCl/G9c Q17RbEb5mQTNoQf7/BzJpW6+SP+E0bywXs/xBV7t5KLinaclkY3+O28EnklB ga4ImmSGwIWMAp2lCww8hM+XxQJrEnKVTEVPvK6QC3dD662gonTga2sWK/gW JgcHP5OlCISgenK20uxTgQxlasAHucCbcWgs7cY3o7YmwltAaGZfxIiP8G56 lXM7N+EaZSwAx+IDXXs2LoPzk6Kziw6sRIBv6EYTkSXm7h76gDbRupeVW1Sb OvVOXw71xUl9lcavYpSk0lwyogHtjtNAkrI8Bfla4W+pKWvvqPklLNLBH/eE cY00o2E3uAlp9QtF41CcAMqwoHuA2w/9OxLhI4c0crqQffyiESrmWPTGEhp1 8Fr00RLT+VrBMtcjSrum8G4OMNboGhzyLhBrsbSgoHTnP/hWlyHspKOT58gU dxMSkXkD/kyBzjxFflJxyHW1OOEVV7N2ORpwywDDpTUOt+y8rtYeeSE00nRa gQMozShUMX2zhvfHIS+G/dS8pkJwWspRJkVbyZY3LFAl5km3FfaGRP6PBZGU 7w+4hMl6qTm4GksusgOuirjUUWa5yW4FIiK3NNdSmV1zVQnGFrAzzqpYCIl6 ZkdYZ7htBusoi1xITsp8M8uFQHghRT98raktzQYubdqvUTEBzSxjGORZwfmZ s2xNSgLWN8W0ZDrugmSehDPRCAthCychFFF9zXUeZfRMYZwNc9fzTX0NtxOM +s+qtzGBkTc0PW3SM17icM1mTS7baevHbmAafkjB4ZgP/G1PGZEiB8i6ZFNc 3RuggZxqleGVgEo3h9SRUogorr3E5sTIRhNFcOqy5HCGoU+3fK4iSh1tDyFB +f1QRzeGkFOP7NUW7RQWbFq7YqZ69GW4ZIWH+VUcGJJJNNuCRBnNpuGcM1wT EXmbot1InSMJn2NbO4y/4Dq3cCnW8iZD6UnuFW0GunuJgvBVKxAlzESA+Hkc uoK0bJoti4AlDaUbFFx+i3PPKGBdTp1MqWh4t1wBXPQv54Q2LVUTLLl5HKrZ qTANT3LZZob5WcLgOVpS7lVQ4chojFcE1nmAeYxDOrWkxNE0dbRLcZSQRgUb Ey4dlZHtym6yRc5mCE+psCMY1qF1xWwnJsl3fJ1q+pMsQQPS6jIFZSFbBztK W2lUTYqNSNWgjL1DgRbr9XLTaLRpeiyljMhuM3Zwq81VOjoAAVzu84ahTZIw iEDelXgpGrG4wEnhOoPAw3FCwCt5/mzH4gPXIQXU87AdTpPzWZDAMK6ydZMY eAiKIFQ9uV2BNhKKTunlx9SMtMV3pOPmxGtLq24ya0WRcnqcPwQyNhGgqJ49 ocdpTQIfG9HS6S0J84b1g+/PI9Cn7xhhCa0IPzDY6U9ELIhtxOh3XIWRrlc2 GjQPVAnzxhRBECFylGo5ZFLUQgmwNK9SLJNMoEklcpCRe5jtj1pUYoqoUuVt YvTd1URTXF6uFKxj6PmW2goRBsW4kXlHC7up8rmg1lHXNC5c0xkRDnJmOyZL LCiZElxJbCAcB+ADLrrtjAhS8loNPknkWJwvIrjnOveohd+9CbKpmG0v15tg 2Z0WdfjjqnwlgeGn6elzDOo7JasXG3dpL88xrzJSskibKOcmpPChFwxcJFhr xZnO5PMz6CadqAQNA1C4ELYCS6WanasNzGaP8M5gXXZSlqg76BJ0pucLPNN9 SC5cFYPcgDkb5hP0KRXTzqRLt+siKiOzJObf7Ubs1nRJEAvBxeEVWVS1hJJz ADr9UaSoQqjKTx+hkE5qfyLuS2RnvPMMSIo0PKbxCz3ATi49nM/pIjZkEFcu mKGaRZUrgyFa8sXZyYko9rE9dYx4WmRqI6OCRGXRFJtgAOPoLLM8joJbvUU0 7l0HevVRmzlWUiUrBVGghjIwE3kdrBqpQpbpWaabjOtxM5gSkZYerjuA3Tq2 67uw3cwc4ozT6M24kLC7yNjMyLViQMtIpu2y/Sah5QgKFOcnvkRBA1Xcus3Y 8YyNExLJHFvspe2Bku+59CpvM3ISi6e5Sf8GIk2ZLUU+seLncINe4oiWwJiW yeUmq6G/POdCjw73xDzMrPSpToqlkGSa4iBHIdI0jq8QACU9mETKMcev6bbw 9SXWiQGflYbVIiQcCd1C3cFwgdesGD7KdJS1yjzh4V1eN0SGSzD4ddNWuFwz NxA2IRII6td8XxKI7LjvOsBDkUjlk2luyewUIigrBQcFxrT0BhG2N6O8aMaZ Ca3KoVo7SPwkFEiiaO4TVwBt7wp4XFVmKO+GzWBjDycJTTTAHxJwHyfW91bM +LS3Hok9zT+nYTNheUWPp42A4az0SRlX4scVpHaGGlTJEE/DBq1C5QPT7CIz Vib6cHLnVjNh7NAzOxqXancAD82oDN8ipWYKBzAd4b2zO7wu0YpQD5u/l5V8 av3oyqhPRCbEQq5rkfC6+zMMSjtu3hF0pKpuqbRTuY3vhKYuMTQaYcP13DGC FRm8CDMQMcfS07PTv3C0SRRFTM3jQTl4ucsPUogKPxlons8QownqZNdZI1nB li61g+Ojp/6wA2uLqenAQYD7UG1bmNsjVZ3EZQFrtQm2aKpbgQLvqipJ3m9j NqpmWIxMUd8vvHPJolMw+YU6YxRY5Y6fkYtU5qWaxXF/bBoke2AIzY+PvlQS 5yk9dgfXm6unm2JJmc7qb8YkclabxRzMbYrlzPFuzhRAgRtjh/hio/rACfo2 qjozwwhGDpPBDbkFLEiT85ie6OkVk0Swm5E9kSvFtQNExq9/yezDm5jf5fm6 f0KEKp3lhP4L4hum7QmuP3EIrPROYoSCdUTvmekuygE3jqGGFQysIjOFHJ75 wABKlAKkGm9iz+ESsuNHzLAkGek4eda/789a8FD7Ewflq72SmC7qF+8tlqdl sCjWVi23fLDPTUtEmBhJLYU8EtQ04yMm5QShmIUdcux4lLuCUpYMkm1XHnA1 SzoPakz9NCcuJ0wYzyGuj4NO4xvGe0Vc8Bidk69JK8PBkQWPqAQxBd7pu12T OwuuVe1EHLagjxWsnsgFhilBd1u8/irCi0CqQjxoMU6Ij0X6DBSZ1kv1vWCR mPzIP6xSKgqW/IxJ8lHKydjSb0JIZXBQisNukz5IL+F/ay/riy7wQPQA+MWk /13iljoEMaTDEh388akUWHNpsZ8oYn+MvsR1hTprbatZkS6ry8TPbl9QPbn0 mAUphSM2Nt+53ZOBnQTi4aDbRmhZVXu5tFTqDZQVSSSsW/CBjdRgiveYopH9 D+krymKDP9H2Hf4s4m+L+Nu67bwNH+gTEoJBanQxd+o0KdK56mus+AkzGdHb D6jR3bFkrTCUqj5BI3hAw9pV73HsPLZHZTAPZJReO5sr6Sjk+0C8R645Xi70 h+81xTyUQ44c8gYB6TOnggEZbTCdBk8CMmQ4DakEi/UtAqSxFfNUjUD9YkFm zCA/x3ZjRqiMiMt8zBdwuNgjtym0hMZV4aSR35BWM+P0QBRUUAay+zR2zLD/ Uy+grOuOQj9YlZB5bS5ROhfOWKWDgNWmC0crHiiQUpyox4KTnldqiCOyPEqa VysZ2Eqy5a1W4xfy8Rfj5AtQ6BDy8otx+sUVmr/xlznoOl+wweELUCXeNV8E iFWKcQbppJonIxW22B8+naK5mINHoBFqaUXtUpvW4Be7tpnoZr/XXj5Ntx6l 3h5jo1iXSSSusL1hWThPzB5NrN5tznZmNNWSR+daY0t2RVpDGBdBy4o29JOP FWk8/8JT9TRlkFIyzC/yjIoWas3dUA9AxZLcXRPsydxyJyvcMPBkctKq9Bkd wX4qa7DCWrast+va5SKoxz1DbXCpsy6jsXhxgFaiQTBO1OP9DVPmYE+3uYZm PBII2N0Yd5uvOLa9k8vOwPxQaFS7gVs/UQfvXsDn/FAzcE2iBAmvL/Ps2oV5 Ob32V58BKvJ3jv5NDlJByQvaKClInDK8+wn7z/oOhWCwbKvtiuuiKl3RGnzg FljWyqn6CflwwidYf2Pi5Ezy+dw5qTN+Bu0V3ZK0QEQdmWQA+C3pzTEdmiOd Vg2DEGDHnn92nOZLUqwp1FS3i2xWIjIrCJvJQaSfDjHdkL/PRleClsPLaZsC i9uHiw7qBBvDC5TvJRYIbr1uObORD5lGf5dBy6QhWcggKNWlQEhjV3lfcxyz uRJ9tnajsOac32t+Z/ysn16jBcZ5WvH4xF2mXFR0GBGvQbnDyIOQ4/+U0OT6 wjX2dj895tr9MRN2uoHWaszJ8qihNyVcyVfFekzU3qAqzUpwCHOU9VXD2EZq 1kkiOCqtO9PN8h1ygB22jS6Qsomei9k7PL5YCxCJiapR+f7Z/coOg752H/Xr L0PKJKPgup5+pqlVgV83aoEmNMg99waOCy75lgK52NCTvaN4rgq5OqYyTSZB 5NCMBc1teNb0pAqmDi24ENVRclNZkl/zXYlY/usoSJx8g8GhmYwQgp3OrtZW 0RKjXc8epzmGD2FYHEulTPyMSGEsvz1Lx6G0SGOlRTiYl4QMqyfuLAdmuqIw vtlGrXscC8r+oLFchxijxWW9WEsf8iSx5zNyQgXrWMGW/Y4QNGDl6BovzEhC oQa+wq89l0kpEp+ESDc7XAC+3gyHnZgomLHZQccUh5RzgADbIHOzvXesIXb0 vZL55k1yLAk5c56CiVt5C2cxxIx0sDd045wVW4k0kvRdISlHbhQQZcTGyX98 HZL5h+RBzqqlernAgRmWRGIMPPmlpng3+riI92UoI4QGaCrRM2fNCNjRO14j cuVofRxM1hFlfW21E9GNAM0KT5AAKy7jZYAvaFX25Ug74QF0igiNgRi5bIT1 zc2/5iTTognRaxigNaaKqAKKItmmzhAl7k91FuFWJVOLlQ0ZB/SsHWlWfvoD xfg+jQ6KIg1FNSzfpSHiozcKugSbzQzDOhIJDxpYDN7qZtvXKl7poltCQlGp 93qbeuJMpyQnw1zqadHWCqvCGiWuceJlMYqDm2K1L6tHMpcoQD4gLqSIjwXN WatLgihbawXBmKNoRLggWycS4RWfF2SJBqTC5lVazQHiTXRdxtyrerO6VLx9 KDyjb4qSQUl7I5npse6sMLsf1bCcMWcm6BFYDvKaqekMayOHIpapPijBYF5F LNpEX2olDKUJJtdUS9nRnWqFp9wWC5ujlIoq9EYG3ELTOex0Ki5S3vKl8M3p i5P0GywqeHHeCeXmw1aU19XyOqRF5enwdYT8bHm77Vo88/eiYiRnDPXaWCqT gcj3Y2aidINOaS0NTRkKSGJuBOpS4m8ViQbSoLuqCkDyYhCmU3fKkXCrTEui rJe3XyWTEoTRBuRLOPn/61HyP0iqsIKPwLWu9uCkIOTgHL7E8JuD/a8e5O9x jx/M4IpJjg6/enCd1Q8QKxxb2XuUTBZFCEnvSxE/Z/pZQiOHoaFxOVXjMt9A IzUtc9lcEEFAFlVuiQyBkOMZasF6RKYQxKVNMW92f7nFwhX66mAfccyJAr86 OuwvksYQOuKRUNMBVho8a1KkENSbjKZPR1ZtN8Ful3lDXElYkQjmA8fl5C/H L9+8ODnnRMmguUdRzgNIGVjeTV09HELFCA1YeCv2vqC0210zfuLHPRBxuLsH 8/z6wfvr1YMrDFOj/8JjPr34PQmbX7Dex4buR/v7KzGRP3oEv4KCd5t9ccfb ohfwA50tsPnH/PUDc1eWkhDgOW6gP5Xq82IZ68CwPu+5Nuv6b53VgTOW4n/g MWBUVerOXfrv/97hMvKMI7vomWI+vMLh0mjs3bsWVbYEs9V4Lw4ue+/5tXaY FrisJn2jOCjUutTSvOkoe5dNzKSxV5V7VJhs1+LdExSqqGSsZgqqnNFx30+S c4L76BmmehIDaYHi9yJLs6DJJWZZGQonKZpmA9yH4cCxBPINV1p2hfgSTlZo Uw2FEwUV+Me8yCiKZ7PG8sdzSRCwkgmKLm7Adth4i3V8N63ZOLBuItmJWRJ5 BywtXzahkpvdbRykho9nEhrEjjarlKRZrpbaIpAiwNcIyexGw/BtPCTWyqAm mp0Xcsc0pMLtbNDKJNCPYpqkQB9NQIvLdr25oQIxu0BIdIcVlFAXEg+tHwpK LEqXFRCS4Fq23mKPmVaGM+UK9NGNwgdJQKS3PLE2oWkIXNwvQ1IWxRz1fwzN XmqJjcTNHXMDKF/xmvZXq6Owrbs7VLXAeY6MNNtebRpXZ0BRCssQVd0ECMFE ExYYFSZKwiU4XhkrLjJFhgfrHcV7NC0a8UhaW+YLl0jl27sS8J7wMpGFeK4o PGBTUuaB2sno3lMywRJkoExRLWMMsrpds95j8WdU+RSpO2dwPz6jTG5PMaaK KZ+DQjGZvhClcVNSch/rzBhy6Cp1YsuYyoKRY5JAy3kQAf3yHZaGg0GsCi1L ksG5v+RyKc7JyQLo0++/PZctk9CLTmEdiTo3PymwKMbUbFSYvc3bxDk50OpY a5pb5FZyp4iizhnpBw8zPiCxGV/uJhQJ0xH9NfxS5aXFppTyAKiJkTKJlkQQ olAI2g3S9bmrt3e435duX4o4h/mXd0hynTq8pOKLYTIWF+/fXmT5mnAZahg0 RaFFEEw+AM3hDR7tSg3pF6evvu+8Ei1oB6Owj/HEwQwRoJP+qWz2PxGmkeD/ KFbVvwD/79HB44eM/3z48NHhwRP4/uDwyeHRZ/yf3+IH8X8MqMzB/zjMWIo/ busNFXb5UME3fU/t3lM88sRJ33oQQIH1QeHnrSQIvLXKcMGPYr8qZPQ87z+m aNHbGyrF5A6spv+lAhG1Fbts9PO/h18puUSZ+vZuyMLfENvrTPYFDTGb5svw 2asI2noAvsiW0ta/GVBYpparx3mh4mphTdwswBzf0KmO5JCEoqwlRhKSwFq0 qWDcaGSvVERZHCLdQnR1suTMULlmdW6Rl2pVOBUfUVBgRb8B9slBDo3CfGh5 ILqbWMB0SIRRshiXx6oZAds8oAQaMK9hHDVm5jE8gYlwaEp+BzJbXKyVhUsN 1udigmp8x9yACFzSPk7On52fUn+Y8pd/pQVZ7fSQetfMswODwjGHLXah5YIw XYsD4EvO4BCwm5BoHOJKEoOpwIgZmOBFJ71cvXV3DT/hj234sgLpAXJklXyq S63ZtaUxxUGQsna9xTizdD1dkB/xvP4o4Nh/kNWZHoxxg/9AnU/9mmGJW1Tg EWFArbBaQjLJVbnskDMnxlGoui4w02TWBKBLIvW9Jsd4ckyaBUlN3VrFIjzm PgZRhYNSacbkERGiPgGlBc6XZKgQHAJhDsR22UEIaQrgD4H2oTuOnVeqFUZn 9OnXK3jmwvf0R/QMxo7ZMO0ccoCQAXw36pTjyiH4Eo8aVQ/iaxjhFZU8SVwV FFf9xEqfwHq0M1TQtUEBAcDNuILpzYFbrWDABYYts20NWdr+e9Rj9/8yTqpZ O/D1mBGh+F2zT4vznKC7kfGx69RUeVl7MSekWmtFCJUF3+8kMjXdQVL9Ud+h +A5eAmZGGmKQ/iF9dHA4Jr1/xzvZON1tYi1Oh1ocxBX1bR/9MTQ93db0u6Gm 0VygewMS6nj/8Ii3bher6sibq21v6lbSm0dfjh89edx/+3Lb22YMw7efPBw/ OToYfznUf7utBQTBsxZ+//vxo4OD8ePDJ+MnQ+NYb2tlDbzWz19bjd7Ot70N 1NldgrgB0UH6eL6w107mUUFhJ4K4b6K6AKChzTNkXkDOffBd7/+VWMxiHgtW Jo0w/OBTkoj+IGGNFBnOxZf0I7xz6arFmSqyDei0y0Kyu/0wotoSYpIiuzN6 J8n/Ap1lIIVcrSROlPgari6NAusbWUWl8B2PJ66/pMB/6dH+72WrQXlL/1g8 FVFA0XnhETp4mr2sJiX4/PGjRw8fp6PH/BqnSmgFdF8gnX2fkkKBiG285nDC sQBgXgcrRATZNyS04t6idUIvCwWxo/gisQ0xW+UR8y1vyUwqgSUkGWjGbH/3 02j3B6Vn3v+z8/RgcljYyLNLMorq7msMVBdzL45edWYtCvMRXD0/xgFg5i7q Xa8VCcyoKzEGSlJMhiZcxpabpC+rAPPi3pTEkCvKwqwJfAZ3Cvj8KhEihtu3 yK+1KK02oeYcCZohdyXPRugp6XZmlH/wOH1ZPP2aiU+ITL+jkpBsJztIL4qn Qst3bmJ3gUL0cX++o96xaED+7kvjGCSgwhgNZ0lwDCJF4mh3J44WPCNQUiDT qmFYWIiKCvJCQEFOkkghHXuh9U0ast967tVb2fz9GkFgOCqCjngy0vrDvlO6 n/A87rjKaLtiWuQVCcjrDsK8u+CBk9HhC3DtLca0wu8Hj2GHY8AhwoY/uNCP VxnHaETLns1x/83ktsZlh9kWlyGDMUVn0hprcaA1t7616AhdTxHeeE+8FErJ vRuxwefvZ8sNBhaEXURDWLSHW2A06Ui7Oua+JksaCpcnXU5zKhgqiA00Fj52 aVTdi/DGBHGYhwqgyUgUCl51V6En1KBRhNUAkSZTKCtStvfYhJrPfAVXDqz8 QWae/nQHK5NkYpooi7EhZJLi72y1OeCvzi8JxopgL3rULdfePtLjASeXwZkn W7Fin/gOyf1A7XHBobizDQf1sD6x4jBCzyGwEhFsgWk8NopqVRAWIMVKHdC4 GwSJcaVmhw73EFFE6P6OY0mBJBtvEuLg4cAuxHoj23DwU6Iq/yR9rXK4OtFo hqXgf/WOpVjhGSkvWVKIFjlw6Ox1h+jp1k0Wc03uNVs+h/i45NqdHZ8+Vw6J H1gxcrbYdyiAIJaqmOSBe4EIskdCIvMYynyJ4DCbjdv5O8bEN0qp1Rg7W5CX zabWglgMvGBMtbGgAN8esSFXmt2i232BxkJD5yjrbS75JkbDesstsc5FndC2 wIRBqJqkVESZY3X8UPT9yJAi40sGxud38p43Eq9qKWiBvTX+9P3nR6je90fT gei6H3ONMVuwhj/yJnMLd1PM26uPOAP0/K+xCB8+DDcfPAw8uPg0JPFpSIcZ EtFEYoGY7mZCiY+d2jzo3hLHTQQRx62xrm98Z9xBoTSRQKI39ybR7dtzv83B u8oELNLS1O4hOWnxaRgnSrNm18q6qJvy+Cpn0E+xt8koEqkaCLLEorjcKJpA JYXT0R4oGcNuNpTHrpiWsWysEbNkzY5nKi+PI+t4P5o2/fsmr2/9GPV9WtU1 ymo1RmUYK1ExjHctYWN52P5NKfEP95A7NODS3rGUYgJPDeWDCe8m0bT+TxM3 rJNEigVR+wS3Gy7X2rA7IxIUUWLcG2loxKOIQhN3Tmkc2dMJlM4pdpb5WOaX ApIXQmC5OkAespvo9pE+xlzLJ2GYY5+DF8reSwED5QkM7HyNkPtuRk2i4UMh 2kBvOgtv6XCaECigkCp9OSYpGYu1MukbtT6OkzDc41RK9HRiZDWKgCzyuuoE DCqQX2QB15IHC7QJzzhblFeYddySURPx3b5zZObM93r2nlqW/8BRCmWexdat xTcXyEUJv3CmwI1tACpxC1LVzt/QSiUE35RUxRoo2Ti/l7WM5Y5hC5mzryRd +cQZXCYGqaXJ76QJ8Uze5/M9ap1SChj6E/FhcCrhC7XFdT8fS0FJFZ+Mzkn9 CKUaBLuP+v3KpaVwVe2F2qF8KMXXSdYCL55u2rz3WPgGEx2+Tprb1RQrY3IO QPfp6Ft4moKF+LCQ+8RnTI5DlIv6ibiRHmzC14aooIhSHJ6sMIiG1aob4hAX oh6TXo8khPZ75IskMovFbuJhe5hTkoDw/klmyh33NxxfEmL0Q+rBkd02i6jj 4VvMneNkyGwa3huwnMb38aLgDP6ic3Wy0GWv2wzEwIp2LmiBva2aHxldOYeP HgeBy2xd8SP7R1+mo0OyqyKbpJAcq8PHgbOFxBclnZMqkc2CbY9m56tsufiQ kAubi4eU8ggfH+1NKTPUF2r1+GpXCvATiS8J35ogBwBxTwvBL4kLPyedc+qG Y6abND0tkzUV50HwRK/J4vzMsCh/1pr9kM/hqi2xc8Sor5T3sDmaQznTESza w0McHeXt3ODbGp/V7KbmIUcnpIbDJrKiwaINCtq8W4Q2vSR5qmatGvrorsY4 YWTgsuoQONtMhHPHGKJ9+cslIF1VFaMJsEVrdpUKlrEflcoD/1umjY7s00XY FnrZnzLNEemKixxTyfMnHjEwOgzw4ou7kJ7FYR6P6d87y5NMoypHcCDWs9jY EF9Lah2Go4cDkpISWzL5+Iyo0dondnvrtBzUzjn9/2B557Y1FVO/hJf3QUrP SrmeUQcoFUC6k8DIg8Bc22lOALK8Fl2XB+np9zW39e7bgnCrFABbVP5PNK1p up/Hfw9mhO22snFsJ/PLyoGX3balxWOxoMikZpRDSFOpV7SiZCfOLaKXztem VMMLvwAXIv5NYQmq4QOfxHyEBqOLPeBh300gqhCcUIpvH14BQdznWopeZuoY hBlDcLGwXdJxmYnIde5lWgpyJCmOEu5csUmMvmRMEYTAjLO+ur0I5EcyQjiD OkfDe65taLj344k49OhD+MuAyfEOWHMSovdkgMhzL9rM/aiDscskpoJhXwPl JlxU3En1kdScKh4/wr0B56JE0H67EqIswUwu7gY3axyNKyDDEBPVOiclmWVA VJCCbWLE07dG8M2uJtl36DFbXlbskqUqPJgwrHb+kGYsExeeG6yvtlxlTns7 DncrYg4jagHimBJWByyYIJJjtQTUcUaZCzKbNrl49tSVBMvzh0OKMDRRWFZH voUvOS+Avt0dR8MJK7Wk6zoJmGWiD8XLzyuuipm/Prx6dUohMztDcYS/lG/X +08+5NodCmcclmRV/vkYl4gfCSlv6yKfRc4Aq4IHKlGLUfsYk8/wfnGEGkJJ fsgadW/PCY6rCCLdXR6Q8Rbvh0SWaVjlRy2FaPsgyFL1LcNOkLY0WMwFGnbc Jrl3gf3hQK1KPKbkvp69T3HguGmw0Hy68CsqWqZkxhZlb/SpGsBY7Cq/aJ3k 1ReoqJpGJUfQV7agceC45jmWOUCGU/V9OZ7sie452Qjfdi83IVZxKEpKNc2g OHcVB+ePUgN05GTd4qK685wmkdcq/SivVe9k9F0IeEYksk4UXxz2VNwGJNsx cnIUySbgPttc3k0SqhAwgi/XRwSuWheUXKVBNcxBFhrkxjE2JhMiUgnnEAHb n0oN726VVN9zEOUZ8WFoq+KoHqMfczul6nbqiaZyKdwhkLtLXzZ2K3c6wJU/ BLnaqgLiwmsXhwnbQZvg1os8BWPFCFGEOOhqSvNgAUIqCVFi2y2Gyj48/OMk +ZMM75AIn+W6yI6tVxzrPbQ2wXAfERCco/OcnU00NLjJcEQ7kW8Moza5DNZ2 92m8gEF8c+bNBfN8yYL8DfyknYl3vUMvbCwmG6gQXkkQwxTD3rP6lsmwxr8Y CplsF+4BkaBR9cVEv7+h9sKhShZqHIUrlXoenO+jYaUXTfzVoiVVHj0fj4Kg bQQU8YDszlrzeGJDBC/N/aNjYBJqKv0oupMNGCD6yAhmdrghh+yHPbnbvcBD N18giF/CO9uod3ba9c5+WpDRRx7saIG3r67KN9k/bvf6sXxahIl4aQ46E0ls 0Oylr2u9xnFxIQHGmqkbRbYhxGuaA7CS7ymizTIVUKLhop9YU3JZZVK/oEGI UG6GFR3OcGb8/4r8XIvaAPLyUpJhRfIKPSb8IpXUwtOEUkkNt6ZWBKEawANY SPHei7obSZviZjSTali8g5Qr4YRRqJlC4TZFtL0URC3CAuJlVoF+YDkxbooE 5rHO1+PYFY0mnCamJITsmxhfEulN8s8VHIvtidapLr7m9qiuLNKMwWdf5au0 v8ue0XmT4MezuyiAN7pb99NRtVjsYsrtbbXhcyTnmORitx0IPoTP3GR82VBQ lIHvFAYZ2tXZSji3cWbXXeqaCgQE3iX+GtXS1P/ArSWh5swuEnf2QZWtk1/2 0X6H+wZd38fFUG2Nz3ZYt2dP0x2SMXfY1xAHYpOobA/j4lwbV/PJvcOh2smm JNF4K5PsCnjYBhbCNrR6KdQ2RFZ3cN5v3DgP4iTk3uq2cbzDsJpxh7ippJJ6 UpGntrElFjPHOi3Bgz3Ee2BTOnZPovbggjPbGpKk1eCHBrZ1dcNuskPeyAF0 UP8mS0IUN989YGsuUs/ZkTuqV4aC7kMPeZRo8iLEKiTaq+KkSyJW+hPR7dkn T/odcIGGsgV5wnSgZS5ZK7GAdm58cLedHYtX6fRYG07R3PBFqTRPbNNi/DEq B67aJOwUGwSx4+YWWPN7ZQ7WPnvfGQKPrKYOE7p6hyAHIfVsKvCuXOMhv0GL HFwkofo5SQhoplNHhcJWBsQ70Gp5IDpa1BSJkVIpK+SsBiOq2VECythRcxMt zWj4Nenky2vFsPlx8eQg5Z8HhLr64MfFwY+LQ4zywfos9NeT5FCeOfryyWF6 cLCfPJQP5j/u/bj35MmT9GF6kBzJh5um7n/5SL5srvhf/A6+ffQIv00fgPr5 oLlKHstTsKSuCXjoMTTxJI1//mfypfw23Zd/8fHHR0fU5n66n/xeHpjJA7Pu AwfyxaJYVPjv2j2QHMjaNORyT9Olf/tB9kCd7g/w++RAVumrNLWQR4Wcov1O Dh7qwA9krf4nLHAEuQPizQskDbaGIRTs6pZk4/JykoxOW7hQGeqKgtOJCWJJ HdhoDIGe7EqWL8aLKVC2noQkOghfc/0dB56DFKhm1fNvT1OrqIWDCtRLEgOP iHB0rzJ0oSIZW+Ef6dwUoLrhBUDnrR0rq2/JZVcL1UnhEOAgrHQpZ2pI4pMI D9I9LvJqhd5QtMmIU4WznC/LqlYthhb0MISE4AWq8BQia42iJdVzacAljhFx xcYmD8j28B6GP/mljnnOV0M94mIlCAST1ezzwV0jwVgFl3iVqISYVnPlNeLa 8S0BSUqrVMWvuyQt1qCnb/yqXAgXaoCaBR0RjnYkXnHAhrf04M3rxDq44GfL zTy3Cq1emqJlfyhsk69kiiKxu04izKPG0W7J3RKxWV89bSHhgoXzgt1mwHR5 Mkc2mcfUGH/6ZZjivowM5qoU0YmtYdZrdF9IuvYcOG1Wk3At9Vr+Z7qrfBrO DFH4E4315o95amZmchAAVpuW890zKfo6rUEyvxpQIdi64LPd1GLKQUdFuXFi QZAngsw5veUK9fl7Po3jwqWE8Oi/RPZhZdyQQDCdxo54wjGchCZA7qtqyUnj 9DLwvwIRLjG/3bG+r7noYmATiPpNZe9ISLPrS27KmFD9pQkjZV84EgXHSjDM UQBD7QkdHLlF+TIuIozGbbG8/1Nn0KTAoHFRgTvnAUkW/b4StYhBFQEDKdH6 CgZntmRr3Cniey5DYUn5XmF8omubMQbS9N8EJBx4DMFI4ydSLMv+5nQr94HS yBeoa18WJRmT9cJPJm+o7eP08Z4tv7JOdyqpT3IDZsGuLVw7vBez3sS/zyzq Vqw37h0KzEwMv6vbZNEIpshsvl5iTWRegeyWjTM+f2ecasUbb4HH2Cs3M/+N OwF0iBgkdJ6sizWxexzKXlGOZVCoZzNitlRRFYaQUDidiIaMitBZElk+u5GS roEL8VlhH0+f04NU8TLoRAldVwnX56Coh/hxw0wNYTPt0FCkjR/3ROvj6tIf O1RuuiUy6403ITYRxntp4/XPf+qA63zFiWueUwyMGrgDbDowcwxCLC5hOAwo wFe2MF//UUSphHgvIPfeuVuThYeMzmxSzt/nsw2HPK+Kpik8WiHTF8g4GDhL oc+kp67YYe/tQxVD1PtWfO7cGcwV5tappYXMw5iiTb93gAUpN1HQBFFIRBth Sc1tK1eahJkpD2l8qi/wD1oa8TWWvdNnFwe1H3sVqMo2sVi6fpi42ytXFN7M Mw7yhSYwq9akHlOPfL5hkbcd6XgQiWIFxyswMHe2+1PMHchwSBHk6pbnJz5t gaXuSBzo9Ru7VGyS6pSCVyYJt2nMkWV55UjmvuyJAxwgxA0L5j8+N4ebbjTZ Vacu/LnHH012gxCANCzOKgz4RQg2g8ld9G8jLiRsCNcYUFIK9LcLLdNBqIs5 iG7HXEBhQFHWorcm2Dj8ZpGhRnzv7vKKTkJI/N+T/9gUuUaKoNLMwVnRaq3h ABhidScqw0uIKjUL2lI+p7Bo7YggqTFgn1JrGrqifAQ7ehC2YUT9UiEkvbTY D1olt6JWDdsn6/Z+0RM+LoIPsPjFRWqiQd1ntHxTmtPD8tzFEptzDDkfdUsd ksHCEfuUWIlQ9zAaZHLnkv6cVD2PM2DF3rwVctgoByeLrKnpiFaYCpWa1XSX 1NzEW2vNptnNI9O0MYWihI8YG4OEuLIq9zpPxGAHCvJpgAjpt5gBehEtnuQO 0DMha2YGVIZ1VNBzAoJ1yZb9Vvh9n77XV7cNxRIRbK7E3f2cuJiBPPJ+MuFA DMg20vVG4o+LBHGgWd2QKZeGr8KPBPJEllj0Uzp0ufvCyXjUouHz14Wt2+Z5 0NPZcTvEO7Pd9RBDw3iAmp4HqTMaiv7QxOh8KFrFzRFOKjwfkzC08fDwyeMv 09FDTl4w36HvKZzrjvk8lZJChsw+zyPnxT28Bz/uvUA/C0IA7lBVzs7dg2UH 6Nu0WzWYPzZ8B4I+QcyKQy/5Yg2irykZVnEGC/5Qhxg9viXrS9CW+fYl0UIp MgrYOpN63yaVcrDmzujLXQk6QSTxbA7bRNiAjENtNYlIYgi4wFENJ7vXXyXP sk3j9UVZDMczxPyHl3tOpb/MA0q5hLdJbwqpxX12QV0F73UcoRpGGK8OGfYt jjn+xGbrgIL/zIlLsYVBoRFovR3GuDIwq9rS/DYgsoL/inOYT38V9NcP4L8e HB49fnJI+K9HDw/3Dw+OEP/16OH+Z/zX3+IH8V958z36q3wC2vY8n24u74H7 ym9YtTPkQ7PVPPkJy2QQ4ukZJXn+M63hf+/74K0YINuDZL3UMmkma/5TM2Gl wp5VZ7UhwLd/GkJTlQE6mQHBFcmA2J3cRAJgalI5i3q2WaGva0auSOLDaMdP XG4FxYzc9lvS6kVoj8yad1H6CIOtV8ZC6nydFTVxTK5ayLCMnCjO8DodXsOp Fwi8rl/B9EP9jz4uHRb3g13ZceshmmSjZjRojSOYM7FVMPq4L6hI1XgFOVaj eyPk2PSliMVKDAFoVnoRwJiL8KakcFPvIgRh4NAsVwdyqwoy0gXcAZjz3CpS SqGRTwqZ3isAZ0vEZZGYU9vCYHVRJSe4np0slXVvagbnscuHrL05odpTkUeK N8sSbw2BKzsi15G36BhSLF2fOynjIpMjVrIfRGJdFZdXrZUC4Ew5GsmsAumz 6iTGGQwGySoEM4bKdz0HBVtMnCFqhJYFW3GrQpjLUvKYjVtioMqs3q0nc3Ol 8+2mj6CNYY+r0nzfoCbA0tpVjhnIW8jbNmgsmiWJZYxVyCD+aidTzH2yTFxu MvR05OQKLDUuiwtZj0SIlQKtHNvVGyMLhZi4nQNFtsWMabJZ4sqDOBFgWkn2 ycz1jlWj6wBx3M0nAdYV05TlwVsNh2g6qEoZdg4nIzRSNYRNiuii8C/wMqFT NCujtzFNcDupBSSusZTWZLnOC0QJ45BwycZ87sFiVZlAjod99WNGLuU4hVJv dHBJrWfcO+PxDAFRrdZq/UOnMZWThUPdYKkSDjns4UR2WB/TLuzGazgm7t6o 6ugIBrpMvRJVRMAyvYNvdK3Y2KI4IgvIOCMCs1PEeUEVzBbi12KrW9ZaoCYl 2bBXkMEWdsYKGtrWWXOV7lKkk0s/s3P53hFT/h6LYZDJV/hEJ1CdGtdElNC8 8X3X7p+SN2woq9hL3Ms2E5Mx27utKMaz16+enby5OB+6VERnmdZkBabilHh2 QCucLTO0oiHSowB/2yWARgk2/1wXl5lmp2jJKyQ7zlwhIx3BYg2UyWRPcbdd skGWfa2GAI6R5G4yKaD1TN8M5df0TpFx9RI2bUBSGNbuSG5CK+yoZaubOBFe h51dztmJFEDxzNRE30oLFkSE/uw5VoazukIBBjJxK0VxG3lDCVQZLdwzrTgc WpUeC2gB8ZZHGUdw13V2yx/uaqlIhzXJDRThUW7X3ipmoeUo5j1jt99Ygx7I Jh9NDPgPkKwINkZkGhVLDlqhVNAra0rT7RMEDgbYT4nXMlVBEXBKfSPGMAm7 oYWFRfvu2erQ/yOJLpVWyxkpgCyp3v13djlCsxfFN5qp4cxbFwbeV9qgmBIK 7855SkbwrsRmZ3EmyXHTVLMiNrT3VrCJPqYTh0qsXsrB1kjLBPcNqbjq9cXn J91DxD7s6L0hy6m4A3T42C4GCN6g0CAhQjaVTg8q0lM+Ix0w2hyCW90o6OWI dmuXLH5+kgIXI/kDucvy5dphslSc44du9+CDE2z/ziI+oCXpBIBbXa1Q8phF RhBVZu/kkpCY0feY4lW09HBZrIF0/Z4xzMcG7gq6O9bVGn+RtB9szDF5rsbE 4hxVtMqaW1ktA2LJhDNsOQaI+CdAoBjk0aA9msQMDVe4LpqCwv9RaAqycEru Ry6elqgnm1natknBCCkqiu9EXBabGAUTuMvrzZuOuYx5XIxA3IOr6SMbb2Es ZeVFHdvfLqKtnonETwnjOiVZjkdL+o6UZ+63gfHyeqO+fHn86vk5ze4lhvPa sab4FbK1kxOu4vRtjPGMsqnwA3MSLrQyM0txDYcCWaMmAWRJkBaJhLs15U8x IwH5FClL1WLBsl2XdWhBzsUCjzDISvJ0MhrAq+E92bVscUvJ9zH32gMduzCa Hewx/WGH7549Qb3DFf3proGx6GjlJM76r096/oUd5l075AIlLYAxPZAxuHtf Zk64OInWkYPHGZWM8pkxIqgbHr2NA4tt08/4coETzi6hmTsnefztN7LC4qGN iI2mTY1QTMbgmDYSgb+N6ONRLe89rBe/5biK+w7r9DcaVTr1p2zquHR4Aj98 WV0bPWkt6wCbpblAVcMgaxzuq+/jRBZ1niffUAVxzrjkepTuLpoBRTtcMmHr Ttc35ZZauMyjMvFFCN/lWtyM4CHoAENvRXVQxhT0u1kBQ7ll3h+062AtMkea rUBV+vOvXaQ//LhXrq+bn/AXKr4Ae7QjtkfDlpNPdpJv8zZaFRocWR08Mo4a EWYiyXbu8Sa7lswB3HqSUrEgKae70S1GXeCXdI2V3MPOWHINe6rYxDJ4IytI Yuw79pSQ536fPPdwbxwVEhrnDZzqU9jCdBtMBkevCV1ecJtPsfS0n2Zw5HY4 EVmHBnqK8ZQGmveTSO5qvoyax1tPo4ZYgJEsD5E5gqhmrzhkRV3TMiyqrflp q0HZhpoUOtJ0YvUxuY5brpN6nSfrugKFe9XEpgTBZFkyCt4qX1FsbaWuH4HV TAN2iZs7XN3s/IoNIGZzlDo4Jrt73B60rdDFk5htMthIN2yDKxYmvVFAFQrK Tv5xhlitr+AG1yQK9EaGgvWmZV3jGvURGjDbRYZ6pcuR3wFZqa0qclH6+j3W zbVl3Cvl8IuT9KUux9DucJomUzkaPZggw1JELvUdZ275gVMJZ+zKJEbyHv5G Szv/dYt/Ze/lL/bFQ6f85/4/D/55+M+H9Dvm3pPgr+zmgjoA1XNerXzur9s2 S7VVjAN6hzImEMCVtr7fgGLZ0b3D8RX2PumswngLV/uWbVbwEjl2ODtYoUmJ Cpw1jY1cm2C4bXNCGe26LDqeX29hH+BS6Ajap+THnXTvQH851F8eunQJO8yi CgZUVQtBNkbL2yh2UlfUBtv4imlqP2Hrm6wceXeWOfwz/5ofOOg/AF3Tl3uH /e8KwpiVt2HgvQd4y4p/dDib1NlpNI6KK0Fo8sheK3vPdU85/TZUAjnYjQ6j tZVxNEM+TxSPkTpX2vcCAtBowom/9BIp2CF1RfVfpVLcdxlR17PTGqZN7Nch Ian7SKgm1kpllkD2OASzsVBvHYsnQprqcmnFFo1oQdBEhvTloev7EdKbBZYd uHZv43YF8PIT290/PBpiLygAIHMh3jAzFvMTG1tFAsFFVsmxe1uPMIWIisFh YTm2OZlhhI7diNxBt7uKuVb7C3VYTpi5qNSsT4NachcpZ9t82TGoo5ZgXHKj RLQe+9LIACO2y97tTx3BH9Ww/EjyJidw4I0djIitBmmWwQkT7cMqW+PqZz/S Jsx/QqVANVn4dQnk+BPoB1dinOKv8CUN4e4ooBSEBF+rSVoIVy9GZlpkB43z xp2VQ/QNtsyf4hCClxQPUHjCVAz3aHFHJRDGZ8nLCJEDJh/qBM6jMxmYrJmn gxYuKO6JnwktwpggQxWmztwn7oBPsWw3vieMFFY3RPjQHRFpQl0dI2yfYnnv pDtE8ixe7vDedT5imZ8v4OSZvEhh5nglqNZHHJW2iEQP3tB3JQyQVD1qshkn DMAkwCVCtuPUBc7isXJlA0FH5C1jAoa/gAuOBiF6GYG2qyTuhoZgka0ZtjaO vHB9v0a0YKi0g6PpmZ3EAKMvTadoqeE35rheZLghtBkx6JCxkgphk/klvLl8 F15dNNhOaguxrZV4yc7wPVqj0Cq8E9rEP7gZZ+kPC2xv0dDktekUsRyad/rK uANG1Nhb0nnoLvw2tJFRWSN9V8jX2gz7OLCL/qli/l4e5BXCJ+c5ZZbzK9FM xQ/g3g9rT48PLTjbvbluIfJHhEhDaYkPGMuAxKV3CH0D5Mkm3zG40RtNecdc VSojzIIJnZJQM4tTbYyX7cYiZOL7Cp5/w+snIp1gjbJwgujPaUQejjvM1Qg4 v9vEw8+NNJRUFtAKQ9HBn5uBx0JLyYec3NNQN+5W3qBOJcOKfAGNAnxOmEyB tY42JQXcwIvQhAtLmX+0sVV83Pe0tXIdoXuYWTkGDO2sS9gIFG55pflzLeYl 0TiR7L6gKq2iaHSUC7fOtry84GehozEnb8S+qLu61RvboGPyEANU1X5S6KrD SYGYg+baYv62qt9i2lNxByVl+njKhh/1+AmmjrWegz5Gpsf60vTAE/yMrtdg 4KqcTmyX48JfjOIL6VkJ9XMyFKrDRNqj5COMt72921K4qLNLEozmi+Xfz+rr n8g0RpIKfkUB5PQWufNYoZdkGm8mYjtP9EaiJaYEQKprp0CfcrWGUbHsEfeG 7wIToWB6rgQgKSZuVeh747aT9IQUf83r7UduiGdQJJ0c4WzTBQZooWxQzPNs mSC9SRoDCHdr0sCApCh1aQP94GraUUeC1TiCFihg2WyVta9Zy2A7BkGKsJWC 2fpVFi9mZGtqu8mOlkDEwpr4nQQXmuIyQmEWnbKetTsUMeLxIj6i5zMJYCdU 4pJjjkQMxaa1KoxJ+pnZa4LCSZ62qF6Fe2G+5YW4DoZ7YbHlhSjUrvPOcss7 /doYUU7Z8Et80oe6Ods6NE6+ogSPuloOvlx/6GX/kldr+AyQyXs2Z9t3hriP l870jShThRipEOjp6sB9iWXJVsjriLpR68UmJYnFZ6/6zLKF+RRiKuPKH3gS lhRcEiJ2csOCJoGBPM3ASVqKBlOY06CAKgnDO6TxWrUe6tnlGW0/caCvzOeN yBHCEzXJcbAcrQ/ljMwX2V3mi35Tgipkxkbd42lXD8YR2Rqk083sXS6ndkoR mlRNZj72dUQxfwiDeaiSOvsWmbPfSALVoetw1unQ8UwymzZ5VksW1pQ7S0ez st2VzX9KRVsc9rMLvUvgBQlXAekseiM63p0ZM8/ze6j2WyMT93p+7wVL8r9v smV/vSgRLapOCnJFkbo+rrwNxBY4kpWkDFu3Y20OTtMkcSYxNG1epV9QcqUS S5ybhrLzMucaPWRj4om4Ua3unvngMIXwlBJobCvnxcYmLvOSLf6Muy+jnfoF abpdI7fDUFK9/gi9CnPK3DaCnuxYgtXjTjN0MFzmvVMb+7VDeStUt8636lNO tFIdAOXRZnq30K/PspgZyfr47qC0jwP5RHm/xJeHxP2twn4nX2BgV5FiNggT Njk7TUcj9kPvpP/7fxOrb66KBehru2Q7F10alGcKLGb+R08kMaK2JQMOmA+i OBJRyzz8jGpqZD6ZKxhbwUaVSfo0moBJ9XyJMY0kI/ajcU6FoamTrg6Clwl1 YmN3rRsRXKGtf0exRd6E/G76QgM8yCLOjxjiKz+x2JRRri/uQhA8CMs51IZQ 9SHKUQNCJGS1H3bMzaImXfocpyjVGwjOphNuC6+z+PeDlD37H0LIPT3MkCrk VpL6Vv/DaHSc9lWk6M3QJScY/iB5iK7HbrahQrrEn0YVRfAY+ey4xN0WvNqZ 1R+PSvdeuLzMZV5etldCiRRITv2geTlKb/xxTxW6TLIaQ6IjXSMYTLBk1Kca 9jZEDWdU/AeHo9dNAXKuu+VdvqQsp1/I3hIMRuVgoP4PwKHXcAyJQbt0Elxl +kjBeM1pKrFH8tg4oQbkKYoS6O+rtoFpDRtPTORJ2axIGswvq5uf3AiS5/BF 45wtVarAPT7iwJq4I+hAuxNPOjpCfxqKsOCDgJ3viQc2KxAc99ibeslgHxn3 Jf9IaqRU6WVG5uX26n7BD4W/0OP6XnGyaCTiFXeJeK7kTj9GoXdfkm8VAXkK BkFGrJtirrBosVvGLr61v/bogZ6uv67WyRsiDqFsw+2iOE+3MUwyQyFx8dZw tLbWOd0S1KScBReCY9LN2yz06MJDwxAwIjVmi/iJjV2uZh65eDrkWco8Z4fm fNyLX+62wGdeBB5rIlsgEAwOQjl+tZzbu7akf/er/vdN0V90+vDkfRFSx1yK CcyTwlqJfaOZVtxHkZ2FHHPKs+GhPi7q7pgzkTjWKzPIlTuMN7EUw527UYFU 88GIt3MMEM0ww7Ho3/+9YDcWI+Dfe8e69S+eptpg4VK4semXPcpve8OKUghu Raqm7t1TbCjlD3p5JRyvbDvGQc9/KnJ249mguoeEZLMfJEqjf+2aR1p5NP1+ xylp1HHYa4FvO8vzdr5u9iI9xaVecIAYBVHKb4X8AkKIBEGDYDSFl90f85TT z0EJm7b8BWhw+it1xb8Vtf1yKL/9fbp8J68X4XVmmPQr3mj0S91OixZ9nfKX qgL8MlAbfd7crsiSolUnWjRATvSIpRd/fXNybkgaVIMiHbphRDxt/Eq5fdsg X4V9o38xXIR1GpDR/gnMgDKdfhoCV8CqEeh0YOz/svg7mpznWBkP8YHT0fff nz7f1TQYewk//cUkHjxEOGyFg0bexgLn8jbU2W0o8ww75mqHrdTn61QP0GnP o0IG9rE6wcUqrrcbyz/olJXqvtAlzZFi5AXfXnJJsUWPjN9Pp4H+ZMkTiSHz B4DatUsKbhGiGYf4j9yOzBAI85ZxzxyIxpeDw6nfeuy2yGk8pyExTfPY8Hpk NHkJOtJvsD6qfNMc7gBrOCHLnAuGkS/FLuAN2jNQihD4yB6RrdNIP5JHXQaq z56lOyuJcjSRvtA0rNXQ4/UHaj2XAEeKQO0V5tYMEuk8ohN4ZrG8NCrxDQXE cWQAfC7vbAseOxxsaagY3l0N4WMH6qmmEnDaKtfW43fG29oVZBat0q1594xj l2B0UguiM6qgeXuTY2qodilREdxnJlapEcgMwBm4OCtHN3XKdSP8aG4LtjvR olsfJlVfg0DJ0CLGjGgJPIRiFqQ1CXFVqYrrmtpB1tIbcapmMny007uPNkK8 31TOS2VyMU3k1jSpjdg9OkjFWupwYpj58IAGutjxouKqESqi2Y4KAy10BW/q HJc+nycj3NpSMBcMK5Uwz0Gmcf7THV4eDBJx4u6OScJ/pq8V1QgWCqMEJppc O1OR13FszBINuZQj/p1iETWjjxfVvYLN4l2muNH0x4fekNnrO/Inw2tSFqtc txK/wFeXBEfC5jNIAGFdI4xWC2v7Fa5rLWibkozFnkAg2/MwDy6/h1Uk2b3U MYGZVcvS/sZJMQFFEk8HOwm/YcAxbVDgPBndGN7c+XGWWFoyuattZ+CbHR7Q c12kew6Hez718MRIgF2oxXip0S7GSAB11dLhIUQO/BsT/ukGhmMB3CTRoucC STEmdwXZryQgjh7ONOSSMa1sPAzRq3Omtkp/vKTY1LAsZOhrzoJ0/h1LVAJl JmIVN8OHWXU1cqC4/CSNGORDJtXkmkkXrZ1FVA0GhK4Res4SkKVYXzgJ7KM1 g14nq5UlONHXMaZjQeQaEpTEQC0qyUIr4EV1hMO6fJ0IYrvChBBQbKe+GLqR cOr9LBwS8gwuVVaKMga5WoOGdh1ZaBeN/ZDGvgLJfIbMLAyePhJ2O0733z/6 8ujg6MnR43T0xV/gqS9CNKTjhTGXHjuU7hCdCsQGOpehoIgZw8z/JFzt29Ns SEu0MlrXomxHoG/tPY4cWYk4srBK+1oqT2QEvzGUqWvFfsOF8kXjorqahHkr sp6QnlRWCOueRH4WheurKkXVEB/UFdzEPF/1TMYZKnQnYBqFby6EGaLb9dfq izyWflpLuGmXSeiF/jZKVbfZnjwQe8xgpPd8neOH47cXS7KZJWwOYJCFONvO Ng9Na4ztw0YG1wbu9IebIHrY0gI7cXmEaKwNTxUBpiE06QJR8hxU0ia8KmQL tz4Xh3BOZA0N4TUIvjMyDMMM5F/vzP6YZqatDiZshYzmiiAObBbhTY2ok0Ta wOJeGK1ISnHs4NH0seiCktNY1R1Wt6g2Ndwd92Z1J/hxZEiS/SBXOAEeROfC lYbtGYV8WrpFdlGhoU29prwuLXRfb0pMVLyZdLg8s1qO4mNqZdMBk11I8FYi Qm34kuJuJbVfiIh8YsYveUYwV5omj0Ay3bnOA2WgE4YXxogIaLGbqSfGb/g2 uM9NgHGJDG3BIQXxvlI4UilRMwFABIUk2YLYGNwln0LW7nTrDanV1e9xQzK0 +72p5iMWwV2Hp3dfh7/n6/D0//rr0NhxzMjUDaBkZc99wu1y19a5Cdx1F/Sa 6NwG8EeXE7sDEfIXlSgLsuna+6DaYtgyncvIidKfP8h6+KhWxJJPNwhL8I5i glI7JXFu6B3Mhp2PHSTxQGKZQGZdEX45rg2wMwUAQfeRVm6xleI5vW/f2riI GamBzPl4BG9JHhM9H4HcMQ6rI/x4OKjuCW7bOjl2lejxzNIxrupLkLn/ofHB TBkWtCKSNemIOazTfJ7PdQGWeab3kGAv9yiM3OSbkkue0lrt270P/WsaM97v IxRmEA8O44G7jfQc6Tw4mwxVjkJwuHBpWYlxKVi9fIdUHZCHUglksaojEjyP aRpMRoY0ZgBjiOZeumlzPADZbWcEHKsGKhJVCBStqo2ZHNB9MlxC7z59v3Ad 48Wn6Gjo7YXuuWRsna9Ac9oJa5OISy19URG+c6iyJIgoZvTtbeskOaPWBl7i RA/cOYziCOlWPdAM3OZkpCqmrf5uZzoOo72rC93J8K/mdSKXkIOsHt5xzkSA T0b+ToArYTHNc6yaEthsT1IkfGLkKAT6nHDMkdRH92UKeKWsPAJJFfhaQjed zJC86xjmTq0CF4YWyZjjZS7EApLKf7OAiEe8SzkqhqZwLTWlGn8k9egr2zK2 5wxGnTU7o0MGcyBnCo0Tk0BGHQk8Er7xISk5gzHyjbhwLKyM3TLEGsZi2jwj R9gyBHqV18gxB0codeLVcxofeb/mk5TlBK3dIOI1JdrSE5ilNgrhHTFyuAAn Y6OYexdGSntlMogvSrd05yn0koy4YbaQ7eqoojdrf6rCq0CwFIj0Lu1e3x00 dnp6t8fj2QlHdZv4NkPh8tZHr7KRhZg5spf4LiAbqurPib4l6x8wObwJS68L tq9mNLt3Y++F4qjQLZxGsjpIK6CMSG6NRKhGo3Brq/GnyyBAA3EjZG+k2AwR TKIrJOZcPeErrthZcwkUicwvpkucAlniCJOSUE/12ZaFVupz7DHBprdcC490 KhQF15kCdc6uCswylZ5PLIfWlff7WDZIDC1xazgs+x4dHs2PDh7tg+z79OXx Gyf7snRH/zXENBFuppWYVIi50CPh4G5WsKVeL4U/KyxZWqGv4jbYCiLlGhcT FjahRR1J6QEEIMZ40V1bc8lp26fEToezwnuADfBmuBau4IP7NYHD/sHf5Rgq 81MQDiVAVOYj+8R/hap75HFGcsXUwnH4k5dOvOH4O4u9ylakceSXyehA+b70 iNlp6j0LG4SLmfxQxuJHZ8jwjI3XJSAFKws8kJgEFZK3w82P28/OcKIAXLD0 wxMPUUFt/cFBOuq3EyKrK3/2kA8jdugTinjAMnrVODpMEYMJBJuQZ6SBzn0V DIU35bEd21jSVW0Es25IYQ2ysLsoiyYxadYMCcpUvRFSUCsVxBrdUVVJappZ Lv4vYVdX2SdzqqevXj+92MakDo4OHx0dHQKTOn568XQLk/K6rfIqOueEcQPk dwePYm0mNgH+52NQwVxoZ37LUXU8yeQax5V+WR5jZW5/Jn+576A/meekPZ4T m03usAd8LBOiKKifw4RYK/nVeZA6J+7Dg9IP8aDkPjwo/TAPSro8KP1leNCz Vxcf4kEPmQc9+8yD/pvyoDBCG7ST7/5T8SBK9vke88Nd4ouv7SfD5nrDGsew KQmEZKyKIYKkUeEgTKMXrBlxuCAZx4HJxiEk57qJ8y+v8veZVr5ku5k34ibH aTCcBQf+By2WcbZuokbLvnXrY4yWvtKoguZ+vNGSMOTZ/UUGy/TnGSwd3N7H cD/MzE+IaqLzH7yNGLJs8JbDzzAHjcxoViOZl4xjjRXUg0gBy/rR8o8Y7Vpd mOqyv2sWv7jJL5+i1UrvvS1GP41MCYz/Dt34uuuxDfYs5fNhvDQRtrVZKQTC K00Eap+rwdmnhkqx3UMal4tW9uDYjk1XOxYaJa+KI1RqL2tty/0eegb3L9q4 fPrhjVPrJVtrR2yuJVOeRK4Fo5/YX6k4xmjY9MrmTW91HenW8j2WKaQqFe3z ZeXI41/Dia3KJggR9zPJ3mGQFWvy3VZZtUHq6IN5M8gl+ME202tMrYUqwrFh lKgDbxpj3IeOcx86qrwiU/WmTmGr5yGWCw7N84AzKclqVMmGQIL2fTyoLzKA AaHWkkOq/Arr3F8uc8kId04WBke1S8AH0tgtITw2Ly3HXI6O6wH9XxR6NtDF vEL3JYavzTmuzR+Y7tweHn5LtVSRjWtRSxm9s+SnAntAFxV5LOljhOAz6WtL B4+PsC6qMN+BARH6gdygkqluWOIOpgiuUQ/Q422mi+4QuMkyNaiofuyLd7Um UYvIZo6H9y+EOH2qjXQ6yH/CbWYs5tGXWPePDBB/eX749AtGElXHMTPlpiU4 aw1Akjk+jGbppXoprCP7wgkt7IoIXGG6CcdwU3KakB5GkRRzzvsl+BghmFIk Cg7/1+0QfEa9x9pwbIaXjXw2vABdT4gd9uAUaYFXcg8BFecefdDTLdo8gY/D jzhdZCG6zcsFiM9HNZg7EGI91seHoArVv0FobJOice6DIoQ1TPE8hHWn03Gf 6/rM0tdspPJBQrf046M9ROu8QY3CBqsYAMTKTFTIimWC/3FhsR2HD91f0X0X jVMuJ5j4Mg8BFhwBET3pLvNjd5bvf6jccZp/5HE64uP0/Dc7TvM7jlNqblO4 vTepW5cXPQEH7hlLl0PuRmCYTtIXWHZxiHn23Wp0eOCSHcj2nlLicY4sZkpL D5kJRQAthlSXJHN3BAJFuYvkU7Z5+YtIbfPDxYHh9/AS8cAwMn7MDyzsAWgu F0sVfr87vschGH/UKbCYrLZJOq04wqBvwtNIpqDm++F3dHyJk9DqWurz9TRt pJBoMLw7h11JPvRNTGKg6618Q89VHHXF/JYmkkbMINAM0ZyFtGhdQdoajMFP NJhI2SAmc06wiY4o8EnUtvhIpvKYmco3X7AoT9af+TRhK5BbWHmP0gbU4olq fjxklrFhE4u5s9TR3z0yI7JyTykvtl3nSisaO9WJyVgwLXUJxxFf2KSOGQcT ZUn0YvCvbg2I2Mnta72oA9/lPGJMCzaDAXMyr7X+rXooyR09ZxwFsTr4Mdts l4dii5Pwg3r80jB6vp4VhMdFWT58zCraGCsUSCTA0R+Lp8NFzZ3s8XA/jXpD uHJnseYlhAcSB0WveMNkYKPGml6IeLdwG83aRwBrbTpZZUJi5BKSBM4YsnvR nj3HeuFUFyyIL2SJowtNvGx+iT7Szv3I2bl7tu2jRwdwbJ7/Rz/09V5xrxzl Q/8dK+EW5Wy5AQ6y/37/QEPIBYgSu9w/TBduLehzaw8O2/bFcnLau7dYiXxZ rECay6ZNtcTIFfoTE5PkauzEjeJbTbVo+a21nYYPvAb0f2dnEp858NadnQ2/ NmUWrXe7FmPrNs5PaWTotqcwLBQoDINDKTcNFpbrukqCJAyKqB2D42GoMrYC y5ZUXCMsVBRxIuov0mqHBxYIg+NdIgKL0wgejoB4cpAut8jNoS0ljO1+rfAR 29pK3U7v3HBDPhymF3z9zp3/8Pu8vd3ntu0zvPDL7EmnQ9/B/RY2bmBoheP7 q/jEeIzhAHO6Lj/KA5re7QH9oPvz9L9KCMbpXSEYv2cHKFwTp8dPLz67P7f4 9Jgo7+f6JBnLiHSPfXh1jufkWslbdkBNJZ2MiQUjYOodwpnFV5vyXWSeThgd ZZy+OEdVqRbqJXMe9xKSUn45Z6sGlCU/O6CsIJyf/0SOVU7oOA0pG1Gq1w7t ULODI318pNuHS4WwhszcM95GqtYZaip3uOEY6z5caRqJSLuoHkukLNXnda+p QMEV3UMXMKVG6thRlbwQzMHUwfxx1OR5YNfk59plZcLswnH2zDrvVyn0zcpz icUA++LT9lrl6nko3y4ZBcGDQEbFbqkwDG40fiMFw2LoKg4RZpLgpk1dIYeE +GfYDIr8Xq2ePkNHPttYXiAbARkNCl9KYoWXCqLFiVTdnJ/CV5U2bBoawJzx H/4Gwysz4lJkZpoLoEInYQTz84jx8xB1xNTlhu2RHQsYa/Xkkdcih2hoQl1K CrRiGgtnd6AGLqn/lq5vam60bwFffbRD/2A8+M4ujSOjcZQC/gN6cW9ElQWb dzC6x8nW0Y5lqLwnRkc2cMUs4NHOqO78wOA7/ZmFTVFJhe42iUwuDp2XGWqx uggZiYF6GhkEImLIxFc5Hxx0Hs7TOOlO3S1a9oCr5rhbPrOa7HECHtLOPe5+ fnjg1s/xxn/l7ntCilip70gLauM+k6ksZAdI7MfsCh5OR4di2l+9K/VPFz/T 4ic93ZMHJX+N0wNUCAOANK9NIoTJ1QE3CS8lb8r+V7wD+fVbIIeDryRBg2jy xz0YoAA/Bo9SwC0ZJ4dfafw1+kPH6cOvhBOiRDhOj74KMF3pD2xU/CnMgU7c 9YFPj4QPAuivFAHIXEhLVNJCGji8fwOHnQZQdQZNurop8/qLxmnS6ajzSqck 1sa9RXp4EbImL913UhLaFWdGsZ8VEEnAZ5BxvDtmJHEgyZRZWcnfjqo6rzJw jkvXnIUHFG7KUoyH3yDPu0uPp9SsyHWsKy1OXIkJ6CbUu1fEqsEZskw1MRBv 8Oe/b6l/OMvF7IFUg4sgpj12vctq5SQbb0aMknVSY6LOY//Bl2Lm5E8QlUPq pP3EnjStpFV6B1YToXvWZkjeBEEtGzqfmbBLO4tdNnvnoXOenFV+vcqad8nz l8dvThE9igpiNO/cE8hWcnmAfk+HkpjL/AY021XC28tcOWiwDCsoRsEdeHan G5e2xodhLtwAal/6CdEoTZcNygz6efL6G6dNcD+Jq0Jie2aDaDbT62q5WQUq ucyVNwqcXjDQdYJzBlFkxM8ebi/adWKcW4zw0xWIfC6XCDdDSq0sqwrOyLJ4 l4sHiHEfRbaWAIL5ppxndEUH0zSmvF274zpdvU+6qTaa7FrVwQ4B3Dwhjm4n yGIiDIxZIA4DK1hg+GBzVdUt14NS1r87FFEoM4u8eIlEK8VuWCIADkmOc9CR J0SOqWGUEetyLDvFlgfvCaVYHD480P+EGzS7OQmwVKKKjcKR8rTNfa/+CoRd 5oCgeKEO716pw49eqY9ciqwkif7LUG1DHiVqKlS/IAlwXpVfILIiF2tLHx4S ixK8KxerN7BLv8qau1Xm6tvYiBS+IuOb4YNFAawCWC9FGVlzowDKlSQhu83y 8wqbHLaQ5ZckLh/j0do+jkdk3euBJaxigd7o/D3u+0dwDZIRSXn86IPfLMjL OEibYYia+nt/woRrn65qiQlUPA6OB/zgUf6VqQj/0lxllzhNzpbBQBy2vfRM EsvqMnlRXXbjipEQRaO0U4Zs9S/fnGNp5S+4ELiUxkOYRi6kIw4xPI+Ji+8e I4nbB9AlQ3M7GFpvTaa7NTkdAOxC7bR//Y0teoIamK7MJ6k8xEFGBsOEuCMZ HMjr451bXq2oRYgh4tvfvJl1tWy69iEX4REaZCJORihF/eEPZIPblewYbrJo QgUe7E3YFklWHNqApjpqm8KFiiYxQKNgZpOzIkNbqtUa43S5G3zXfJyZSBq4 Xor/0pFzOpYQqXeEPgVRttUtqqWi2JJkpjGQjzoVobiOD0qIbucFnvnTtx4a +KX2XseixePsk54Tu72p9ubwStmwscJY1sHjcOeoLZ5PIS0fdxhEc19rBnGo khFyqXy2Ia4i0cERITW7xHYE2NxKTXGRJQZE5Px4ugIFep131HkmiK/Ry76G k1UpGqFFVnkfUT9XESJTEVXtwT4Pd33AbdYwnkDUNLde5kjd2EGoUeNNJ0PS 7YVRtq2zSuShhzGF6wqiYv85qzzk5q9As6Ns/jcQxMs28tJbDBLFR5MByZ7z rThltZl23FVT0HCN/nadBWvQBio161s33UYRHrbBDXER1PAKdiux6fve1ibQ y7Rt6inEU/s1LVuU1kPF3wdFc404QS5e51gWg3g4HKgNo6iFcXiUXsQ4XWWX WLriUwC6XFMDCF2PHz3k+Ntvzn0CMM8Fr+/hMBC9yIP6IMq+O5A9L6NGaXmV u6+F1R/f0h06Xd1X4rtsINUiadqzcKdguEHLTR87vkceEycV0IlJAkbZlhx7 i8O8TEciMOwyCjPKWRaNu29Pob6M48Ynd8IsKw4lIi/sUAEgvdeHr6bus3IR dLm5FvQcekUNM53FTbfCsAWDhuKF3lGY6kMtsBAY1rRXnc+vQ4++uovSaR6W vffKMsh8vdrQzSDQnXtKNb7IbnIRbbgLBxqnh+P0IaEMH5m7Dy6VI65/q9c9 fmRQ4kchIlZ4E35DUbbZfF6IXyBgAB8o46zq4pLKvolGc0gPKWRcgF2/yaXM 7yR56B/pWEDx/iNvGSlLfG/v+pePLNYclx7YtTYgByMOk4LJOpzncXd+VnoY o/sodmq0/35//2D/q8GhjxP89hC+7Y2688wRPEOhVL1vvoRvRLxbbpqWrqXi stTUAcYpw0q2GK+1Dw8z04PBoHtn66OH+KiIZc0VzGv+9rpUwayx/qHF/a96 FQDSts5m78iYivcoPnhIDw4CoqlaCm26mxg9KXicG3os5vk+WE0goB4dHMYV B51M4u8y9fbwpkn4aTdaibYAO+eFHb5v4Ls1h1aGQymbt5bMW38mg22WNP4K 447yFp1a4UGGttPn1picOfgcfhM/TF2gKoglESxXTa/QNFrW7mO61Gm8AN3H bFXS7hL0nuN1SSMG2xldYLqjGhNwsSLDejfm5t2W9Sb1AwBt65IyMXr1K5yo Q9UH8LNsKijKlGmp9TDZ5ocxwv2LtFhl79+uZ22iReNgb1GCzC7zjmDAtmDT 5pxf29HMlmvCkDHDkxTfsf3B9C4IzcWALITqx2B48oB8MqirBGFEw4ZdBfLB K9nii6Ng0OjZr3nho/umA+f5d2ak/C6XnnO89eArXwg9m9ECR5xn/zB6hKLW pHhwSfyOGemRMFiuLYf66jRHpWxDWPihgYae/vKrOMJ1sGdk+/FTWzo/3L+z 86gNd7fzKgjsP/0xSXlJqBQcbOB8j35bsbqqASs33pdmvJ1/69x3oP7wx9gY tRUo3o0EtpSvEjXEcgSKu17ukp5AsG0TuZHg5Jwdnz6nz+yBm2KOeLrxE/Rh kP6LOuYxvWxCLjM8KCrFFjW1s55HdlanW23Yiw+LYTbf2CbLQtS8yuFQVWrE xogO5+kPmCoKs4eEI/XO845Z9ym5ONdZozE0FN/mU1eHBsDSVg2SSY2ys9ox ZJpYJevTQSISA4lIfzGQCEy/mqHyVDZfpd/1ECMonoMMj1QW6fj82ekpeYak KsXz0+NvX70+vzh9dp68ROvFCg0Vl1L6Z4alJXy1VzprklxGg8KikLsaafS1 WEKpOEM1o2IZIfSBLhU6q3CrcO/nJyfp8Yvz172LaGxvZHNQauKPrJFx77IK n3h7a/jUV8wMn5YDLQZNXyI1tIYY/7k9jsPHcFhz6egRTPl3v8jP5AGs9ZcP aDqYUIkZLZMvf5m29QcEz/3HR0f47+HhwQH+e/Dk6Al9Tp/tH/3uAJ94ePTw 8ODx7/YPjkDc/l26/8sOY/hng/p5mv5uWmabv1Xvtj63bi9/i+H81j+Ti+/S aPPTL+kwvTp+eZLEX/y4l8qvjZbrtRNQoHEqmIUVIhs/5bP511ev35yfnicS uWWtJj/gRz/uXSY/UblmLvQIv7WoM7bMVk7On52dvrk4ff2q/z4ZUef5dMOV cduqWrJkFsYaSt/yMEP9PCnp1yt/25mIGPpteFbhy9d/7QdWdlbHXIs2uS3t gHAJYozZC9XC5BdVVX43qALLJAdrfnfSRUMSBDPgpp0XpTjySB4RzZ9LE4Ow j1GBJV9CJN9j5Xl0qGXsulhZWdkMq7WGuqyUCsH3PrkzwvIaGVk9RFkErQqn kAx0Fwoet0QavHnT3/fmqtqAJiyF39R7op3Y5KuSCpWzN7VjhduUGJ2b3FYb q7SOih5IFVrMrx0aKW5PXd0y7vsbotDXRJznerEjOWM52MbGo0pSSkGYc1jo /o3Zm2Kdt5u6bGT46GaZk8pDsfOZoBmFbcbauRgVttgsSfaU7ETQwgj0FFup ayxLPgNJvxm4M7ffad37a/jixHuJWn36/bfnyckKs2XhXErptsaRw/+vappJ c1lMYM3Tyb+aB/53/vH3v2z9L339f+j+f/zk8SO7/4/24fuDh48fH32+/3+L H7v/9dx3r3/9HG5/kovx2nc8tF9Vfvi+l2b0us8Xl9VN8lMqfy6Ry4KQjQFo HycHaLtbxQBXndbGSnegiDBuLjYFu6K6971Wqaf48qy9ogARue2l9C9XDcw7 0Wzdrj5NFsCbkY2OXDZdXu3e/HKNU8JDKQUl6crZduHTxZ1EF/fHX//xPa37 Itc06eruniZSGiqGC/pvx2pC5Vrc14SDU/0j9/aMRlNo+GpC6xmaGr7cBT3p dSsQH+wrCMIfkfWMhjel8GOOaMIlw4DHqq4363Z4VmhY4HJOS7T3k/rPJc69 9FtShayb7NbkR90wlcgof78tLjcI/jdCyL5mDdp0vhuFSFA4FV/3bim+aAJB UxQtpcRTbEaIHVELQk7yDZwEFgB5Vk9v0YucbZbtuDfDarrYNGjuxCo3Tets OaEURL8Wr3zJ1Z2lKDo2hwHgXN+0bCm0iZNZr3PLtlmwU5XqugSPWHrS6yJx 5VH+kdcVfoeR75VZNHiebN4hMuJihlYm1qaSRGUZZOhq1D1CIqDsLQt9JQcN I98gmmRTuabc27CFoRDzSFxVJQ+FZC+DkhwwmWuxbtxB5o0lMSL0hfw7fzCl ovRkTNtN1P5s+wUTf0VjkUrH6SNany8Hp8FB9w2V36Wm1uirpsgG1+BdB9vL 352acI1YsSj7jaxTxp4lL6gix7h3iwK3mS7zlcBWEOWhOYjsv3hmmlleZnVR BQBM4vQFrVg5IK8mC5BCG1YN6LOsy4azrp5mtXi5gEiSldnyFjgDr8OF5it0 tMh4daQNE8Kh/65enI5WRblpLAxiNyqI3dWaWCutlnfoHHly3lbrxg4dlRxn pY8Ef6ynBAdriZWWCyl0XVyWFcWq6EN8spE9Jz0NQ0PVOPcEIZomofeFFk7W Y9CJPzMLwTT3AXoeRAUHe0l1+ugGHVHSHZsK7ZDs8W0giW27GoxK8QJwILn0 sag7sp1S+Dra+KusScjAjzWj00KUxKqec+SWBNi5EEy1CU76Oh6ttSp4MqDe 3SuhPfGtHZRdfg52YPA50xip61MUmBCDi+SlHUaGc1chAyJhOJHwIQpBhael hHhXwGAgA70yEv8GEnAxVxSZ6JuCL0BmtmPmbpT/Kw8Qr02EF4dFq5LnXKO9 MQ4jFhOTbrZdLo1r5iZ5g/bYJuAkkO9XrnAMujKqzUsJtRTAAFrmSfoUKF6f 4TXG82Dj3aKb6/n+oGqOJ4qM5Nv0c7mNTTuXYu5eRZei0nY29WMXe4+nno+C BFOQ8P764uQ8OW76XIllYWccEV5g8gzcu5TC3TUu3RFIKuWnYXiIxZluiTwN lJgQJTI6RqAgLJfdIR5dIgawu0VhFbeWUsTQzdTWWdkwZmyT9u9BmYSFfzNt DV9mdBabK8SGuKmRhcDCk1M84sbzKbFhZEdhRclXscWYMmQ2iVj6eEBkHXf6 u8Mv8QsYXJz+z6P9xbX/D+n/D48ePX7C+v/jh4ePHh+i/v/w6LP+/5v8qP4v pNrR/uVTsvyz9NRVmge1fX5Ydf35i5flm+s/BW2/IsaymQLj+nGW/AD/g4// gP+capLFT+HpFp+mmwXxQIdNBvphjR/WrZkR+HJL/onf7pHKbBaKAWOCDJv/ aVQDRM4mwbeduTeJ1zrxMO4GuLJQJVTv27kX8GxspvfztS1itdgY5HKOzAwY 0ExiurDdhKNduyim3nsBPDmEimtjitbHfYw7i0DSIV4Gq3XL0qvCYGY3Oqys aapZgbw2MXD8MFnfOvFwanLDuBK+mZC/Apz5LL9EZCiQpMbde0TdCzg+6FJt MWZFcGieYwkJbhDgIzb6r7Lbu9X9IdF6SLh1e+gjwjOjskH5FY6DPRDLsCtC ztkiwCYDAixHqJgckWoE4KA0K6F5IisUq/XS5qJlC02080hVcr3TFFHA5lKk naZtnV6gMApbiulQ/weUc8p/pI+aDn3BEFF7t5hmTDOWxDcKSqhbuOosRcQk FlBiMRUCztmf0dqlByrMrEMzRHOYQYs7Ayub1UJGst+U3MXRCZmS5rJqSJzc aGQGSVwPKq7luE0KPx+Squk0KCxCsMpERhwvFwV5m3ISWMmlyrb3ke8nyfkg xS2F0said3Mh20iI0AK4iHCKprFQCVf5DrI+6iNMv4bpE7P9GbO3PG2VIz9y BXqUum0R6l9qEfodGvmXyauKwRJuCctjksZso3MGnAlFXupQL2g9qTegNkio sRVQTX8FgWnesOOb768bepGihEzVhcF+9+YjbuHJtE5eX4P2gaFTN6rWq02Y WRacUsajZIy6eA5JsWBsNgTEwmzRm1LIozGoFbZn0UhSFOYxXWXNYaJZQFjZ L4z0CkQH/wP/Q5axSoao5EdGTQ3Kxpg+rriBz7Iq28GjSPyjPoOJwgVZcfyS qoA3zG0yunPCYZjyiKYfGNF0g4g69xtS9OynjGkNd3b1B16FtxKOOjwsjdQm VTPDkOzB4FlsEjjzH5A9f3SDiFzcba69wgf+IP++lTTgqMUQEovQTctlvpSn FV5dz14LzEilxJ3kJZ8nszHaV5P0+aZmDRIhgzdl92Jil0hDxGpee7id4LI7 eJSiyQ4tEelZaJkx0jh3mRRPMkVyzQoeKxu68hINAvN0JKvkbUkv1SySdt5j NmKGu66ouikldb+9QY4br5gsVJpZSqzP+f5x74116vbJgPayct6N4GQwdvH5 wHuYiR+/yoBuB499iolivWC9jtJLC9fJn/J6isydF919NQdBkBSOOd73oIo3 y1uq4FTd9AWJbbqJ+o94jLhJwTrX3q4FMwoHlbCptKJQ0WXOb3OkDOcfkyyw YrSW1Sqfo9RL15PLT4dupgjeASLkefoMoyOa9E1eozcDxNXTIHDOuNxBLc42 hfNtPWDAV8gcEQf41DbDHUnMUBpJBQQsOsOhlM1XyRStWh4NvhAg3HHvq8a+ C21KCKrVo64oGohLbmGlaRl06vOmuALx9rY0LX6ZAaua96LmEbzyUoG7sUx7 P6fO2rB3tbEp3rOMr8YAewHDC9GsTrswpjiuDy5V6kcv+SeEcZM1dtNy17gL FKlP2QZ7mD4TKRasFilAjnvTgpDHijFslWDse6/5MBwHexxZii3KxBrpzFAH 3Zm39mAgnM1Au4lkoGe6GHxLpw9BrEKerovXQ3JyO8K9RwqWoItoKs84CYyF rorSgGMpYB11OZf4w1bCocYMMAiGeDQBdqatbttkItQuVxumbAeiknVf4dO0 pdBE/LyvNsFwFASfyEEKyLM2ZcgsIWraRXKCk4c6H2ekC6ngzbiEfcJ3rfbW qiAWwCSos5hXDJ4F/+Kv9rDOSc61FFlBQNHuCTdTfpiJwn363aPI8w/tDw2F BB3aqEeT5I3GTug+sZpFEewhKw3bjc9FFqIuQlotsOmkc2AIDiUB3Y9Yi72D kQvAJTiVBkbyeJK8sKREG4vLU4xPyGVU+jBIamE5+vWcHEN6wjWkIh4UHx7i JXr85VHUAUjzdicsC0ydG9iU0bd6BvHdcLZZDPKN87i+hLON6XnpU86FkLGx PLoI9e1FCWZg3D3Bs9hQaolQzdgrJpd5BWo7YvA4TjBOGF4AbQeSTEBZxSE/ kAFU6gy4pRTlePMmeV2vgcNroEgkmiChjOwEjYUP09Q3ZaCeXXJH4W1Vlnzt IgL0MpuJvWyVhnDPZdW0/4uKUoatlbpeSEVZ0xCP0jzHTuYVXP7P0UZ3Qu7U jrRC6W8UBSpRFfDg6YPX4nslRaCmzLgxGkM0MhVWEf3kW5zYRKM3mUEEKJxp xs3PawK/AJ12A80m8Mq68WbG7F1Oobt52RhUKXqw+hB9qnHSQop7iwx76Lmi vySrT+yGwuMYuGZYZutaKo9D9R8gnqtKUl21Pt98ruHZ5AtR17lE+aaXVTVn /FraBrePF1c+7qOzx+r84oQajF3B6d1yzPDAAkxzLjfChkjLvna1ULVFakGd XTFUqSAtqsNsG93Fg2nGdz5LOOsYwjwXI4fCObL+QnaWvgIhQjHvf7BvChBJ WaXCO8sFiP0t5xSBwh5GkE6S70AKvkZACaFaOHR0VBTasTNkKY13TWWXqC98 szM2jFjfwGV6CcLImIelSILc/Jyqp6ploX8Mn7GND547D+wlQR2BrKcVMHLl P3RDGWdy3GjSGdSGs6qi655NIl1GRkkE0ZaTDR17oiI3Uvxk6E2asqahDY1K DxqpdfmczKznfKR9k3i8q0ptnVKXJlfMKYwCIgERWcu2nsaRwQcNUE3nOCSY dLnEjVwUikOqEwRGU622tDxJjlveVRIs6JRoTA0B4/TWhXf1PygHEw+dpOOH 5HU9acZDBoxuZBGeLVGGprFVhCLTVzr6FX/ooDdVvCJUngGHK4EInD8o24PE TZVnMopeOOXQgMFSQng4xn5Gc1bN5+bt39qjVo3KFwvgA3xhvqrawdkbZ+Lo fZwJ7VXRUoyMz5EFztTyWUMnN8ViMFgVnu/wunslmtMqK8UhgticXZc4bP4S l1JTtikeMl6R+OzUeYi3wtUgUCwyw3bjjBpT+0lUkyXFcA3KGaUaR9YCj36l oP+dttBXhPcjUwr2tjUyxHhWs/EM4joPOZCoPrZ6ZLGuKSmEVFqaAqtaLdpa zkOo1bQk008qoXUiaEG7CUc+yJP8Lt3lk+QlihaWg6S9xxkumPBfUzgFXdxk wSJCquC2vrmq6HlMNAUSvOTLPZh3AwjTAP7NeRWclSvJ8V8RBLcbSf4eZC+q DonMfxLolT0woPVsJL8/mgR6U5dodEa7TUAn33JzYMxHtefs8XAug5snnCc5 ENApxybeYrWCS8PCh8FFjagm39i+saUd1IRtgg1awXFEGvpK+oO1ionjFpcC XQYZlaH3J6eU381ViVfVtRx6d59SKdcyugLzOfvNqwRFQ1HRSgvv7ozPaXQo 3pNUl/HZj1/aKh+76gNItyoje49z95ZOJmen6YimxoBH2VbJ5mMkqsGVRPPz R62mQGnKyYjm5vFFWb3DsXc/pUdbQhTgTLhYZhoncu3gqlBVDaDldESO31vE OQPe417vSJhyKbCukGDedJddhqkPw6K6J2zFCtJNUZNsVI/SNSNKwke4jt/Y OBEqlQg2qbD5g7YnPFBqb4palObYO5g1AoI5UJ4iHDrzv6uxTvz55A8cWdmO otWvPB1IgIae/c16Lm0OD3xwZUJlmHhdVAb5xVZG5vTpayOsTdqJaEY38hPX A7HXWnGsxAtRMpQ+WWXg0/cEdEC+xltbCe0OC/MRicIVXDRAvQgSKmHrdEV3 ykIGAg4FIINRMxqJogx5S7XZZthonRvAZXB4BKs89u8a6NSIwFU4JczePS0L QgC+bDZ1yyE0Q/HxLNzDd1N65A3bp/VheTKLH4vgQUdi5dlF44WVpOYoe6k2 0L952iZfcrVXi6LA+ENMIta0lDCPQktdEwPF0FgC8eEipJHEkrdXkvkiMfvp 0kFOk3PM6FTIkakTgakai/Rm9b0eeEn2U0A4KZMbVTcfDny66HJmdM7vkVg4 qttdsZJ5GSJtEKuqqUAANTMZ54nx8qtBrRk0xAcFmzu/qXDsJOWIHZ+aYSEp 0zptNIBbRgZFpdOa+Ggymm/WCvA1mUw+REMSrCMvEGqIRr+ItdA7T2bCCwZL FEite1LbKXFEK36/V9wUCjDjFnSpB6W1pLjXphlMWOgh3He9V/ihwK07POnH vRTt9Z2VO7alkfJYvjIa8mZ1hXZWt+uMEmM6Ca5kbzYY2a5o7BcHYxyWGjBD yztGNBkOT+G0AN6IaKXvscAKIhoW7kPLBWtzFxm6pWT+DXNG4RCVIpaUVR8g 0eOmroI7InYKICtQ8DutDU7LyKuN0206qTJmheGhkuLuBOM7h8UjMYN9OOwk Em/Uak3KDSuFdjPh1Tj3HJ9MZBspIcZBek2kTigCIJJIz1+p7CSMLV82xq3l KBCjRg4M+7G8DVYbYNPqrJYMDtn/hLCu81k+59bRAarsKKhMnmnfOm5c5vSe MgRaV08SncomnhjOggBNL5LaBE/Tg/fdjiFuz7szyO0xk65bbWW3u20kliT9 Byckz0tAqNZQHJM1xvVg2jQzoJpCAcMxcXKd1pIJOHPxqsDETfihxGnOYx0U gpzCHwss2ofmzDIohNm8I9kFE+BoeXtCjFlEPeMIMN42E+Ea4tGR5rQS2QcG 5VY7rgPDC0duT5w84S4Sf0ZRjgJoi/qtCo4DXsTJhCPRKFpolL6Hn3Q3tCCn 3+lzf9uU79Q9OtCl18+i7mVP4tfufsfJkz3dz6jBWcZxHSeTH/+/UpTAN66M zLRcsoiadds/d6b9w3w7xM9iBV8o95hIaGnAgxHx1xuy64LoMUVTIB32ATNF mg0dMVbUqRyNqAFO0cbKuPVHkolfdnGN9LT8fxlN0L416nwbXEwV6L04lklZ TQI+ZnE+djyqT9C2lvVN1oqkhJJJlRfuivCA/WWgPLiBMZ7M96J40zdcwJIh e13lGLbLNUCbV3WGWinZvHADkh1nU6cuduI99Xs2rDzHZ+Gpo3HCHoxbN+Gt d47uPqTlhzeCNOL0wq+y05g/cr27azhwzGixaStiJSUsbroTkS8KrztshD75 y+lFen5xfPF9xwhNgcij0iKRqYwL+z04bTE1FE8ssYCc3wlcInbgzUw+ZVPR 4bxK0d57PN51m3WNnzBEjdjnTBPGEO6Oz9IqJyHN7aITG8XyC/ojzO3JjllG 67D45yTATSAxlYTeT5c5W9jVu40QgXAHSekvMtfPUVJNRq3kAm4Mvs+qolJx Qwahvdq0c6Co3TGHXsRMEU56jWG/4XkSWSZbCnZwdj0mOnTHPhanRcFamXyf YCqqTE58ULDypbrPIweMy4PsOofmSL2wWTVZ0v5WTVE0QnFsMCn3Ysgj0BEe tU66jwTBEA2zrgoCZxPXB8V3RYymFhjHs0XzjpPSZPPlJJIrKgukNQ3lYXmJ NzjOkMwfuwgEjhKPkKTnhDxVc55kmIebYUnCU5c7OyP7VdGJ83QRN1KrTkM5 E9B64IakXK4ZGkOo3nZjxcuRRjbT1qsCqCihJIyN7W6bAqWzqLcMTwPHAFim NPlxEjNRKOSCaTNIQ1nJsKnvvYWHXFhoykgYPtfyqnkkp50UJUNecFlb461w C+beS6K8+wiWD5dOkRn4RiMQwqyggMVcc3sYsEF4VkziTAkSyVSsYGLX+VD2 LgaaHBgcZxdKdNPB79yCIzqIpfZLgnd+/vn88/nn88/nn88/n38+/3z++fzz +efzz+efzz+ffz7/fP75/PP55/PP55/PP59/Pv98/vn88/nn88/nn88/8vP/ AoUbrtoA+AIA ------------Rr7cg5yEJuo975mRgBBBmL-- From owner-xfs@oss.sgi.com Tue Jul 10 08:53:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 08:53:03 -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.1 required=5.0 tests=AWL,BAYES_80,J_CHICKENPOX_66, SPF_HELO_PASS 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 l6AFqwbm025076 for ; Tue, 10 Jul 2007 08:53:00 -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 l6AFqksl019662; Tue, 10 Jul 2007 11:52:46 -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 l6AFqjuU022185; Tue, 10 Jul 2007 11:52:45 -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 l6AFqhIL009495; Tue, 10 Jul 2007 11:52:44 -0400 Message-ID: <4693AA69.5080009@sandeen.net> Date: Tue, 10 Jul 2007 10:48:57 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Timothy Shimmin CC: Martin Steigerwald , David Chinner , xfs@oss.sgi.com Subject: Re: Fwd: xfs_fsr and null byte areas in files (REPOST) / file data checksumming References: <200707092313.48876.Martin@lichtvoll.de> <20070710005030.GQ31489@sgi.com> <469302B7.7090306@sgi.com> In-Reply-To: <469302B7.7090306@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: 12099 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: 758 Lines: 21 Timothy Shimmin wrote: > David Chinner wrote: >> On Mon, Jul 09, 2007 at 11:13:48PM +0200, Martin Steigerwald wrote: >>> 1) Is there an XFS qa test available for xfs_fsr? If so I could use that >>> one. Are there some hints on how to get started on XFS qa? >> Yes, test 042. Download it from CVS, build it (installing all the >> bits it asks for ;), edit common.config to add your test and scratch >> partitions (both volatile) and the 'check -l 042' to run test 042. >> > Yeah, get the xfstests package and read the README in there. > If the README is not clear or you have other trouble then let me/us know. ENOPKG... just cvs. I'd always thought that packaging it up for distribution might be a good idea, what do you think? :) -Eric > --Tim > > From owner-xfs@oss.sgi.com Tue Jul 10 12:24:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 12:24:26 -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_99,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 l6AJOIbm019890 for ; Tue, 10 Jul 2007 12:24:21 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I8LJk-0003Jb-EQ for linux-xfs@oss.sgi.com; Tue, 10 Jul 2007 21:24:12 +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 ; Tue, 10 Jul 2007 21:24:12 +0200 Received: from jp by cm169-230.liwest.at with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Jul 2007 21:24:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: Jakob Praher Subject: Re: usage pattern: xfsrestore to mirror disks Date: Tue, 10 Jul 2007 21:24:06 +0200 Message-ID: <4693DCD6.2010106@hapra.at> References: <4691C1BA.4040603@sgi.com> 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 Cc: linux-xfs@oss.sgi.com X-Gmane-NNTP-Posting-Host: cm169-230.liwest.at User-Agent: Thunderbird 2.0.0.4 (X11/20070618) In-Reply-To: <4691C1BA.4040603@sgi.com> X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12100 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: 261 Lines: 18 Hi Timothy, thanks for your quick response. I will apply your patch and try it out. Timothy Shimmin wrote: > Hi Jakob, > > I wonder if other tools might be useful to you... xfscopy,...? > that would be very interesting for me. -- Jakob > --Tim > > > From owner-xfs@oss.sgi.com Tue Jul 10 13:11:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 13:11:55 -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 e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6AKBpbm030758 for ; Tue, 10 Jul 2007 13:11:52 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6AJ89LF022910 for ; Tue, 10 Jul 2007 15:08:09 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6AKBpES544744 for ; Tue, 10 Jul 2007 16:11:51 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6AKBpPl028498 for ; Tue, 10 Jul 2007 16:11:51 -0400 Received: from amitarora.in.ibm.com ([9.124.94.136]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6AKBoQ5028326; Tue, 10 Jul 2007 16:11:51 -0400 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 1014729EB55; Wed, 11 Jul 2007 01:42:02 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6AKC1GE006552; Wed, 11 Jul 2007 01:42:01 +0530 Date: Wed, 11 Jul 2007 01:42:00 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com Subject: [PATCH 0/7][TAKE6] fallocate system call Message-ID: <20070710201200.GA10255@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 12101 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: 1526 Lines: 42 This is the latest fallocate patchset and is rebased to 2.6.22. Following are the changes from TAKE5: 1) Rebased to 2.6.22 2) Added compat wrapper for x86_64 3) Dropped s390 and ia64 patches, since the platform maintaners can add the support for fallocate once it is in mainline. 4) Added a change suggested by Andreas for better extent-to-group alignment in ext4 (Patch 6/6). Please refer following post: 5) Renamed mode flags and values from "FA_" to "FALLOC_" 6) Added manpage (updated version of the one initially submitted by David Chinner). Todos: ----- 1> Implementation on other architectures (other than i386, x86_64, and ppc64). s390(x) and ia64 patches are ready and will be pushed by platform maintaners when the fallocate is in mainline. 2> A generic file system operation to handle fallocate (generic_fallocate), for filesystems that do _not_ have the fallocate inode operation implemented. 3> Changes to glibc, a) to support fallocate() system call b) to make posix_fallocate() and posix_fallocate64() call fallocate() 4> A testcase to test the system call. Will post it soon. Following patches follow: Patch 1/7 : manpage for fallocate Patch 2/7 : fallocate() implementation in i386, x86_64 and powerpc Patch 3/7 : support new modes in fallocate Patch 4/7 : ext4: fallocate support in ext4 Patch 5/7 : ext4: write support for preallocated blocks Patch 6/7 : ext4: support new modes in ext4 Patch 7/7 : ext4: change for better extent-to-group alignment -- Regards, Amit Arora From owner-xfs@oss.sgi.com Tue Jul 10 13:18:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 13:18:17 -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.4 required=5.0 tests=AWL,BAYES_99,J_CHICKENPOX_63, J_CHICKENPOX_73 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 l6AKICbm000428 for ; Tue, 10 Jul 2007 13:18:14 -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 l6AKIEH1028291 for ; Tue, 10 Jul 2007 16:18:14 -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 l6AKIArc268296 for ; Tue, 10 Jul 2007 14:18:11 -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 l6AKI7MX024952 for ; Tue, 10 Jul 2007 14:18:07 -0600 Received: from amitarora.in.ibm.com ([9.124.94.136]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6AKI5vT024792; Tue, 10 Jul 2007 14:18:06 -0600 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 03C3629EB55; Wed, 11 Jul 2007 01:48:21 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6AKIKKS010272; Wed, 11 Jul 2007 01:48:20 +0530 Date: Wed, 11 Jul 2007 01:48:20 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com Subject: [PATCH 1/7] manpage for fallocate Message-ID: <20070710201820.GA8797@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710201200.GA10255@amitarora.in.ibm.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: 12102 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: 2962 Lines: 121 Following is the modified version of the manpage originally submitted by David Chinner. Please use `nroff -man fallocate.2 | less` to view. .TH fallocate 2 .SH NAME fallocate \- allocate or remove file space .SH SYNOPSIS .nf .B #include .PP .BI "int syscall(int, int fd, int mode, loff_t offset, loff_t len); .Op .SH DESCRIPTION The .BR fallocate syscall allows a user to directly manipulate the allocated disk space for the file referred to by .I fd for the byte range starting at .IR offset and continuing for .IR len bytes. The .I mode parameter determines the operation to be performed on the given range. Currently there are four modes: .TP .B FALLOC_ALLOCATE allocates and initialises to zero the disk space within the given range. After a successful call, subsequent writes are guaranteed not to fail because of lack of disk space. If the size of the file is less than .IR offset + len , then the file is increased to this size; otherwise the file size is left unchanged. .B FALLOC_ALLOCATE closely resembles .B posix_fallocate(3) and is intended as a method of optimally implementing this function. .B FALLOC_ALLOCATE may allocate a larger range that was specified. .TP .B FALLOC_RESV_SPACE provides the same functionality as .B FALLOC_ALLOCATE except it does not ever change the file size. This allows allocation of zero blocks beyond the end of file and is useful for optimising append workloads. .TP .B FALLOC_DEALLOCATE removes any preallocated space within the given range. The file size may change if deallocation is towards the end of the file. .TP .B FALLOC_UNRESV_SPACE removes the underlying disk space within the given range. The disk space shall be removed regardless of it's contents so both allocated space from .B FALLOC_ALLOCATE and .B FALLOC_RESV_SPACE as well as from .B write(3) will be removed. .B FALLOC_UNRESV_SPACE shall never remove disk blocks outside the range specified. .B FALLOC_UNRESV_SPACE shall never change the file size. If changing the file size is required when deallocating blocks from an offset to end of file (or beyond end of file) is required, .B ftuncate64(3) or .B FALLOC_DEALLOCATE should be used. .SH "RETURN VALUE" .BR fallocate() returns zero on success, or an error number on failure. Note that .IR errno is not set. .SH "ERRORS" .TP .B EBADF .I fd is not a valid file descriptor, or is not opened for writing. .TP .B EFBIG .I offset+len exceeds the maximum file size. .TP .B EINVAL .I offset or .I len was less than 0. .TP .B ENODEV .I fd does not refer to a regular file or a directory. .TP .B ENOSPC There is not enough space left on the device containing the file referred to by .IR fd. .TP .B ESPIPE .I fd refers to a pipe of file descriptor. .B ENOSYS The filesystem underlying the file descriptor does not support this operation. .SH AVAILABILITY The .BR fallocate () system call is available since 2.6.XX .SH "SEE ALSO" .BR syscall (2), .BR posix_fadvise (3) .BR ftruncate (3) From owner-xfs@oss.sgi.com Tue Jul 10 13:19:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 13:19:53 -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.3 required=5.0 tests=AWL,BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6AKJnbm001164 for ; Tue, 10 Jul 2007 13:19:50 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6AKJpWU026703 for ; Tue, 10 Jul 2007 16:19:51 -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 l6AKJmZg256738 for ; Tue, 10 Jul 2007 14:19:50 -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 l6AKJmYq001426 for ; Tue, 10 Jul 2007 14:19:48 -0600 Received: from amitarora.in.ibm.com ([9.124.94.136]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6AKJjvL001262; Tue, 10 Jul 2007 14:19:46 -0600 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 16A5829EB55; Wed, 11 Jul 2007 01:50:01 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6AKK0gD011224; Wed, 11 Jul 2007 01:50:00 +0530 Date: Wed, 11 Jul 2007 01:50:00 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com Subject: [PATCH 2/7] fallocate() implementation in i386, x86_64 and powerpc Message-ID: <20070710202000.GB8797@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710201200.GA10255@amitarora.in.ibm.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: 12103 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: 10134 Lines: 279 From: Amit Arora sys_fallocate() implementation on i386, x86_64 and powerpc fallocate() is a new system call being proposed here which will allow applications to preallocate space to any file(s) in a file system. Each file system implementation that wants to use this feature will need to support an inode operation called ->fallocate(). Applications can use this feature to avoid fragmentation to certain level and thus get faster access speed. With preallocation, applications also get a guarantee of space for particular file(s) - even if later the the system becomes full. Currently, glibc provides an interface called posix_fallocate() which can be used for similar cause. Though this has the advantage of working on all file systems, but it is quite slow (since it writes zeroes to each block that has to be preallocated). Without a doubt, file systems can do this more efficiently within the kernel, by implementing the proposed fallocate() system call. It is expected that posix_fallocate() will be modified to call this new system call first and incase the kernel/filesystem does not implement it, it should fall back to the current implementation of writing zeroes to the new blocks. Signed-off-by: Amit Arora Index: linux-2.6.22/arch/i386/kernel/syscall_table.S =================================================================== --- linux-2.6.22.orig/arch/i386/kernel/syscall_table.S +++ linux-2.6.22/arch/i386/kernel/syscall_table.S @@ -323,3 +323,4 @@ ENTRY(sys_call_table) .long sys_signalfd .long sys_timerfd .long sys_eventfd + .long sys_fallocate Index: linux-2.6.22/arch/powerpc/kernel/sys_ppc32.c =================================================================== --- linux-2.6.22.orig/arch/powerpc/kernel/sys_ppc32.c +++ linux-2.6.22/arch/powerpc/kernel/sys_ppc32.c @@ -773,6 +773,13 @@ asmlinkage int compat_sys_truncate64(con return sys_truncate(path, (high << 32) | low); } +asmlinkage long compat_sys_fallocate(int fd, int mode, u32 offhi, u32 offlo, + u32 lenhi, u32 lenlo) +{ + return sys_fallocate(fd, mode, ((loff_t)offhi << 32) | offlo, + ((loff_t)lenhi << 32) | lenlo); +} + asmlinkage int compat_sys_ftruncate64(unsigned int fd, u32 reg4, unsigned long high, unsigned long low) { Index: linux-2.6.22/arch/x86_64/ia32/ia32entry.S =================================================================== --- linux-2.6.22.orig/arch/x86_64/ia32/ia32entry.S +++ linux-2.6.22/arch/x86_64/ia32/ia32entry.S @@ -719,4 +719,5 @@ ia32_sys_call_table: .quad compat_sys_signalfd .quad compat_sys_timerfd .quad sys_eventfd + .quad sys32_fallocate ia32_syscall_end: Index: linux-2.6.22/fs/open.c =================================================================== --- linux-2.6.22.orig/fs/open.c +++ linux-2.6.22/fs/open.c @@ -353,6 +353,92 @@ asmlinkage long sys_ftruncate64(unsigned #endif /* + * sys_fallocate - preallocate blocks or free preallocated blocks + * @fd: the file descriptor + * @mode: mode specifies if fallocate should preallocate blocks OR free + * (unallocate) preallocated blocks. Currently only FA_ALLOCATE and + * FA_DEALLOCATE modes are supported. + * @offset: The offset within file, from where (un)allocation is being + * requested. It should not have a negative value. + * @len: The amount (in bytes) of space to be (un)allocated, from the offset. + * + * This system call, depending on the mode, preallocates or unallocates blocks + * for a file. The range of blocks depends on the value of offset and len + * arguments provided by the user/application. For FA_ALLOCATE mode, if this + * system call succeeds, subsequent writes to the file in the given range + * (specified by offset & len) should not fail - even if the file system + * later becomes full. Hence the preallocation done is persistent (valid + * even after reopen of the file and remount/reboot). + * + * It is expected that the ->fallocate() inode operation implemented by the + * individual file systems will update the file size and/or ctime/mtime + * depending on the mode and also on the success of the operation. + * + * Note: Incase the file system does not support preallocation, + * posix_fallocate() should fall back to the library implementation (i.e. + * allocating zero-filled new blocks to the file). + * + * Return Values + * 0 : On SUCCESS a value of zero is returned. + * error : On Failure, an error code will be returned. + * An error code of -ENOSYS or -EOPNOTSUPP should make posix_fallocate() + * fall back on library implementation of fallocate. + * + * Generic fallocate to be added for file systems that do not + * support fallocate it. + */ +asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len) +{ + struct file *file; + struct inode *inode; + long ret = -EINVAL; + + if (offset < 0 || len <= 0) + goto out; + + /* Return error if mode is not supported */ + ret = -EOPNOTSUPP; + if (mode != FA_ALLOCATE && mode != FA_DEALLOCATE) + goto out; + + ret = -EBADF; + file = fget(fd); + if (!file) + goto out; + if (!(file->f_mode & FMODE_WRITE)) + goto out_fput; + + inode = file->f_path.dentry->d_inode; + + ret = -ESPIPE; + if (S_ISFIFO(inode->i_mode)) + goto out_fput; + + ret = -ENODEV; + /* + * Let individual file system decide if it supports preallocation + * for directories or not. + */ + if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode)) + goto out_fput; + + ret = -EFBIG; + /* Check for wrap through zero too */ + if (((offset + len) > inode->i_sb->s_maxbytes) || ((offset + len) < 0)) + goto out_fput; + + if (inode->i_op && inode->i_op->fallocate) + ret = inode->i_op->fallocate(inode, mode, offset, len); + else + ret = -ENOSYS; + +out_fput: + fput(file); +out: + return ret; +} + +/* * access() needs to use the real uid/gid, not the effective uid/gid. * We do this by temporarily clearing all FS-related capabilities and * switching the fsuid/fsgid around to the real ones. Index: linux-2.6.22/include/asm-i386/unistd.h =================================================================== --- linux-2.6.22.orig/include/asm-i386/unistd.h +++ linux-2.6.22/include/asm-i386/unistd.h @@ -329,10 +329,11 @@ #define __NR_signalfd 321 #define __NR_timerfd 322 #define __NR_eventfd 323 +#define __NR_fallocate 324 #ifdef __KERNEL__ -#define NR_syscalls 324 +#define NR_syscalls 325 #define __ARCH_WANT_IPC_PARSE_VERSION #define __ARCH_WANT_OLD_READDIR Index: linux-2.6.22/include/asm-powerpc/systbl.h =================================================================== --- linux-2.6.22.orig/include/asm-powerpc/systbl.h +++ linux-2.6.22/include/asm-powerpc/systbl.h @@ -308,6 +308,7 @@ COMPAT_SYS_SPU(move_pages) SYSCALL_SPU(getcpu) COMPAT_SYS(epoll_pwait) COMPAT_SYS_SPU(utimensat) +COMPAT_SYS(fallocate) COMPAT_SYS_SPU(signalfd) COMPAT_SYS_SPU(timerfd) SYSCALL_SPU(eventfd) Index: linux-2.6.22/include/asm-powerpc/unistd.h =================================================================== --- linux-2.6.22.orig/include/asm-powerpc/unistd.h +++ linux-2.6.22/include/asm-powerpc/unistd.h @@ -331,10 +331,11 @@ #define __NR_timerfd 306 #define __NR_eventfd 307 #define __NR_sync_file_range2 308 +#define __NR_fallocate 309 #ifdef __KERNEL__ -#define __NR_syscalls 309 +#define __NR_syscalls 310 #define __NR__exit __NR_exit #define NR_syscalls __NR_syscalls Index: linux-2.6.22/include/asm-x86_64/unistd.h =================================================================== --- linux-2.6.22.orig/include/asm-x86_64/unistd.h +++ linux-2.6.22/include/asm-x86_64/unistd.h @@ -630,6 +630,8 @@ __SYSCALL(__NR_signalfd, sys_signalfd) __SYSCALL(__NR_timerfd, sys_timerfd) #define __NR_eventfd 284 __SYSCALL(__NR_eventfd, sys_eventfd) +#define __NR_fallocate 285 +__SYSCALL(__NR_fallocate, sys_fallocate) #ifndef __NO_STUBS #define __ARCH_WANT_OLD_READDIR Index: linux-2.6.22/include/linux/fs.h =================================================================== --- linux-2.6.22.orig/include/linux/fs.h +++ linux-2.6.22/include/linux/fs.h @@ -266,6 +266,17 @@ extern int dir_notify_enable; #define SYNC_FILE_RANGE_WRITE 2 #define SYNC_FILE_RANGE_WAIT_AFTER 4 +/* + * sys_fallocate modes + * Currently sys_fallocate supports two modes: + * FA_ALLOCATE : This is the preallocate mode, using which an application/user + * may request (pre)allocation of blocks. + * FA_DEALLOCATE: This is the deallocate mode, which can be used to free + * the preallocated blocks. + */ +#define FA_ALLOCATE 0x1 +#define FA_DEALLOCATE 0x2 + #ifdef __KERNEL__ #include @@ -1138,6 +1149,8 @@ struct inode_operations { ssize_t (*listxattr) (struct dentry *, char *, size_t); int (*removexattr) (struct dentry *, const char *); void (*truncate_range)(struct inode *, loff_t, loff_t); + long (*fallocate)(struct inode *inode, int mode, loff_t offset, + loff_t len); }; struct seq_file; Index: linux-2.6.22/include/linux/syscalls.h =================================================================== --- linux-2.6.22.orig/include/linux/syscalls.h +++ linux-2.6.22/include/linux/syscalls.h @@ -610,6 +610,7 @@ asmlinkage long sys_signalfd(int ufd, si asmlinkage long sys_timerfd(int ufd, int clockid, int flags, const struct itimerspec __user *utmr); asmlinkage long sys_eventfd(unsigned int count); +asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len); int kernel_execve(const char *filename, char *const argv[], char *const envp[]); Index: linux-2.6.22/arch/x86_64/ia32/sys_ia32.c =================================================================== --- linux-2.6.22.orig/arch/x86_64/ia32/sys_ia32.c +++ linux-2.6.22/arch/x86_64/ia32/sys_ia32.c @@ -879,3 +879,11 @@ asmlinkage long sys32_fadvise64(int fd, return sys_fadvise64_64(fd, ((u64)offset_hi << 32) | offset_lo, len, advice); } + +asmlinkage long sys32_fallocate(int fd, int mode, unsigned offset_lo, + unsigned offset_hi, unsigned len_lo, + unsigned len_hi) +{ + return sys_fallocate(fd, mode, ((u64)offset_hi << 32) | offset_lo, + ((u64)len_hi << 32) | len_lo); +} From owner-xfs@oss.sgi.com Tue Jul 10 13:21:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 13:21: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=1.9 required=5.0 tests=AWL,BAYES_60 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 l6AKL9bm001820 for ; Tue, 10 Jul 2007 13:21:10 -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 l6AKLBBs019329 for ; Tue, 10 Jul 2007 16:21:11 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6AKLBiW543634 for ; Tue, 10 Jul 2007 16:21:11 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6AKLB6M027958 for ; Tue, 10 Jul 2007 16:21:11 -0400 Received: from amitarora.in.ibm.com ([9.124.94.136]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6AKL90a027864; Tue, 10 Jul 2007 16:21:10 -0400 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 2065029EB55; Wed, 11 Jul 2007 01:51:25 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6AKLOts012039; Wed, 11 Jul 2007 01:51:24 +0530 Date: Wed, 11 Jul 2007 01:51:24 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com Subject: [PATCH 3/7] support new modes in fallocate Message-ID: <20070710202124.GC8797@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710201200.GA10255@amitarora.in.ibm.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: 12104 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: 3894 Lines: 87 From: Amit Arora Implement new flags and values for mode argument. This patch implements the new flags and values for the "mode" argument of the fallocate system call. It is based on the discussion between Andreas Dilger and David Chinner on the man page proposed (by the later) on fallocate. Signed-off-by: Amit Arora Index: linux-2.6.22/include/linux/fs.h =================================================================== --- linux-2.6.22.orig/include/linux/fs.h +++ linux-2.6.22/include/linux/fs.h @@ -267,15 +267,17 @@ extern int dir_notify_enable; #define SYNC_FILE_RANGE_WAIT_AFTER 4 /* - * sys_fallocate modes - * Currently sys_fallocate supports two modes: - * FA_ALLOCATE : This is the preallocate mode, using which an application/user - * may request (pre)allocation of blocks. - * FA_DEALLOCATE: This is the deallocate mode, which can be used to free - * the preallocated blocks. + * sys_fallocate mode flags and values */ -#define FA_ALLOCATE 0x1 -#define FA_DEALLOCATE 0x2 +#define FALLOC_FL_DEALLOC 0x01 /* default is allocate */ +#define FALLOC_FL_KEEP_SIZE 0x02 /* default is extend/shrink size */ +#define FALLOC_FL_DEL_DATA 0x04 /* default is keep written data on DEALLOC */ + +#define FALLOC_ALLOCATE 0 +#define FALLOC_DEALLOCATE FALLOC_FL_DEALLOC +#define FALLOC_RESV_SPACE FALLOC_FL_KEEP_SIZE +#define FALLOC_UNRESV_SPACE (FALLOC_FL_DEALLOC | FALLOC_FL_KEEP_SIZE | \ + FALLOC_FL_DEL_DATA) #ifdef __KERNEL__ Index: linux-2.6.22/fs/open.c =================================================================== --- linux-2.6.22.orig/fs/open.c +++ linux-2.6.22/fs/open.c @@ -356,23 +356,26 @@ asmlinkage long sys_ftruncate64(unsigned * sys_fallocate - preallocate blocks or free preallocated blocks * @fd: the file descriptor * @mode: mode specifies if fallocate should preallocate blocks OR free - * (unallocate) preallocated blocks. Currently only FA_ALLOCATE and - * FA_DEALLOCATE modes are supported. + * (unallocate) preallocated blocks. * @offset: The offset within file, from where (un)allocation is being * requested. It should not have a negative value. * @len: The amount (in bytes) of space to be (un)allocated, from the offset. * * This system call, depending on the mode, preallocates or unallocates blocks * for a file. The range of blocks depends on the value of offset and len - * arguments provided by the user/application. For FA_ALLOCATE mode, if this + * arguments provided by the user/application. For FALLOC_ALLOCATE and + * FALLOC_RESV_SPACE modes, if the sys_fallocate() * system call succeeds, subsequent writes to the file in the given range * (specified by offset & len) should not fail - even if the file system * later becomes full. Hence the preallocation done is persistent (valid - * even after reopen of the file and remount/reboot). + * even after reopen of the file and remount/reboot). If FALLOC_RESV_SPACE mode + * is passed, the file size will not be changed even if the preallocation + * is beyond EOF. * * It is expected that the ->fallocate() inode operation implemented by the * individual file systems will update the file size and/or ctime/mtime - * depending on the mode and also on the success of the operation. + * depending on the mode (change is visible to user or not - say file size) + * and obviously, on the success of the operation. * * Note: Incase the file system does not support preallocation, * posix_fallocate() should fall back to the library implementation (i.e. @@ -398,7 +401,8 @@ asmlinkage long sys_fallocate(int fd, in /* Return error if mode is not supported */ ret = -EOPNOTSUPP; - if (mode != FA_ALLOCATE && mode != FA_DEALLOCATE) + if (!(mode == FALLOC_ALLOCATE || mode == FALLOC_DEALLOCATE || + mode == FALLOC_RESV_SPACE || mode == FALLOC_UNRESV_SPACE)) goto out; ret = -EBADF; From owner-xfs@oss.sgi.com Tue Jul 10 13:22:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 13:22:43 -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.4 required=5.0 tests=AWL,BAYES_99,J_CHICKENPOX_66 autolearn=no version=3.2.0-pre1-r499012 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6AKMcbm002599 for ; Tue, 10 Jul 2007 13:22:39 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6AKNqUO022641 for ; Tue, 10 Jul 2007 16:23:52 -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 l6AKMfpO557356 for ; Tue, 10 Jul 2007 16:22:41 -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 l6AKMecv011709 for ; Tue, 10 Jul 2007 16:22:40 -0400 Received: from amitarora.in.ibm.com ([9.124.94.136]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6AKMcwS011571; Tue, 10 Jul 2007 16:22:39 -0400 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id C8AB029EB55; Wed, 11 Jul 2007 01:52:53 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6AKMrZ5012869; Wed, 11 Jul 2007 01:52:53 +0530 Date: Wed, 11 Jul 2007 01:52:53 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com Subject: [PATCH 4/7] ext4: fallocate support in ext4 Message-ID: <20070710202253.GD8797@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710201200.GA10255@amitarora.in.ibm.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: 12105 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: 20294 Lines: 575 From: Amit Arora fallocate support in ext4 This patch implements ->fallocate() inode operation in ext4. With this patch users of ext4 file systems will be able to use fallocate() system call for persistent preallocation. Current implementation only supports preallocation for regular files (directories not supported as of date) with extent maps. This patch does not support block-mapped files currently. Only FA_ALLOCATE mode is being supported as of now. Supporting FA_DEALLOCATE mode is a item. Signed-off-by: Amit Arora Index: linux-2.6.22/fs/ext4/extents.c =================================================================== --- linux-2.6.22.orig/fs/ext4/extents.c 2007-07-09 15:24:33.000000000 -0700 +++ linux-2.6.22/fs/ext4/extents.c 2007-07-09 15:24:39.000000000 -0700 @@ -282,7 +282,7 @@ static void ext4_ext_show_path(struct in } else if (path->p_ext) { ext_debug(" %d:%d:%llu ", le32_to_cpu(path->p_ext->ee_block), - le16_to_cpu(path->p_ext->ee_len), + ext4_ext_get_actual_len(path->p_ext), ext_pblock(path->p_ext)); } else ext_debug(" []"); @@ -305,7 +305,7 @@ static void ext4_ext_show_leaf(struct in for (i = 0; i < le16_to_cpu(eh->eh_entries); i++, ex++) { ext_debug("%d:%d:%llu ", le32_to_cpu(ex->ee_block), - le16_to_cpu(ex->ee_len), ext_pblock(ex)); + ext4_ext_get_actual_len(ex), ext_pblock(ex)); } ext_debug("\n"); } @@ -425,7 +425,7 @@ ext4_ext_binsearch(struct inode *inode, ext_debug(" -> %d:%llu:%d ", le32_to_cpu(path->p_ext->ee_block), ext_pblock(path->p_ext), - le16_to_cpu(path->p_ext->ee_len)); + ext4_ext_get_actual_len(path->p_ext)); #ifdef CHECK_BINSEARCH { @@ -686,7 +686,7 @@ static int ext4_ext_split(handle_t *hand ext_debug("move %d:%llu:%d in new leaf %llu\n", le32_to_cpu(path[depth].p_ext->ee_block), ext_pblock(path[depth].p_ext), - le16_to_cpu(path[depth].p_ext->ee_len), + ext4_ext_get_actual_len(path[depth].p_ext), newblock); /*memmove(ex++, path[depth].p_ext++, sizeof(struct ext4_extent)); @@ -1106,7 +1106,19 @@ static int ext4_can_extents_be_merged(struct inode *inode, struct ext4_extent *ex1, struct ext4_extent *ex2) { - if (le32_to_cpu(ex1->ee_block) + le16_to_cpu(ex1->ee_len) != + unsigned short ext1_ee_len, ext2_ee_len; + + /* + * Make sure that either both extents are uninitialized, or + * both are _not_. + */ + if (ext4_ext_is_uninitialized(ex1) ^ ext4_ext_is_uninitialized(ex2)) + return 0; + + ext1_ee_len = ext4_ext_get_actual_len(ex1); + ext2_ee_len = ext4_ext_get_actual_len(ex2); + + if (le32_to_cpu(ex1->ee_block) + ext1_ee_len != le32_to_cpu(ex2->ee_block)) return 0; @@ -1115,14 +1127,14 @@ ext4_can_extents_be_merged(struct inode * as an RO_COMPAT feature, refuse to merge to extents if * this can result in the top bit of ee_len being set. */ - if (le16_to_cpu(ex1->ee_len) + le16_to_cpu(ex2->ee_len) > EXT_MAX_LEN) + if (ext1_ee_len + ext2_ee_len > EXT_MAX_LEN) return 0; #ifdef AGGRESSIVE_TEST if (le16_to_cpu(ex1->ee_len) >= 4) return 0; #endif - if (ext_pblock(ex1) + le16_to_cpu(ex1->ee_len) == ext_pblock(ex2)) + if (ext_pblock(ex1) + ext1_ee_len == ext_pblock(ex2)) return 1; return 0; } @@ -1144,7 +1156,7 @@ unsigned int ext4_ext_check_overlap(stru unsigned int ret = 0; b1 = le32_to_cpu(newext->ee_block); - len1 = le16_to_cpu(newext->ee_len); + len1 = ext4_ext_get_actual_len(newext); depth = ext_depth(inode); if (!path[depth].p_ext) goto out; @@ -1191,8 +1203,9 @@ int ext4_ext_insert_extent(handle_t *han struct ext4_extent *nearex; /* nearest extent */ struct ext4_ext_path *npath = NULL; int depth, len, err, next; + unsigned uninitialized = 0; - BUG_ON(newext->ee_len == 0); + BUG_ON(ext4_ext_get_actual_len(newext) == 0); depth = ext_depth(inode); ex = path[depth].p_ext; BUG_ON(path[depth].p_hdr == NULL); @@ -1200,14 +1213,24 @@ int ext4_ext_insert_extent(handle_t *han /* try to insert block into found extent and return */ if (ex && ext4_can_extents_be_merged(inode, ex, newext)) { ext_debug("append %d block to %d:%d (from %llu)\n", - le16_to_cpu(newext->ee_len), + ext4_ext_get_actual_len(newext), le32_to_cpu(ex->ee_block), - le16_to_cpu(ex->ee_len), ext_pblock(ex)); + ext4_ext_get_actual_len(ex), ext_pblock(ex)); err = ext4_ext_get_access(handle, inode, path + depth); if (err) return err; - ex->ee_len = cpu_to_le16(le16_to_cpu(ex->ee_len) - + le16_to_cpu(newext->ee_len)); + + /* + * ext4_can_extents_be_merged should have checked that either + * both extents are uninitialized, or both aren't. Thus we + * need to check only one of them here. + */ + if (ext4_ext_is_uninitialized(ex)) + uninitialized = 1; + ex->ee_len = cpu_to_le16(ext4_ext_get_actual_len(ex) + + ext4_ext_get_actual_len(newext)); + if (uninitialized) + ext4_ext_mark_uninitialized(ex); eh = path[depth].p_hdr; nearex = ex; goto merge; @@ -1263,7 +1286,7 @@ has_space: ext_debug("first extent in the leaf: %d:%llu:%d\n", le32_to_cpu(newext->ee_block), ext_pblock(newext), - le16_to_cpu(newext->ee_len)); + ext4_ext_get_actual_len(newext)); path[depth].p_ext = EXT_FIRST_EXTENT(eh); } else if (le32_to_cpu(newext->ee_block) > le32_to_cpu(nearex->ee_block)) { @@ -1276,7 +1299,7 @@ has_space: "move %d from 0x%p to 0x%p\n", le32_to_cpu(newext->ee_block), ext_pblock(newext), - le16_to_cpu(newext->ee_len), + ext4_ext_get_actual_len(newext), nearex, len, nearex + 1, nearex + 2); memmove(nearex + 2, nearex + 1, len); } @@ -1289,7 +1312,7 @@ has_space: "move %d from 0x%p to 0x%p\n", le32_to_cpu(newext->ee_block), ext_pblock(newext), - le16_to_cpu(newext->ee_len), + ext4_ext_get_actual_len(newext), nearex, len, nearex + 1, nearex + 2); memmove(nearex + 1, nearex, len); path[depth].p_ext = nearex; @@ -1308,8 +1331,13 @@ merge: if (!ext4_can_extents_be_merged(inode, nearex, nearex + 1)) break; /* merge with next extent! */ - nearex->ee_len = cpu_to_le16(le16_to_cpu(nearex->ee_len) - + le16_to_cpu(nearex[1].ee_len)); + if (ext4_ext_is_uninitialized(nearex)) + uninitialized = 1; + nearex->ee_len = cpu_to_le16(ext4_ext_get_actual_len(nearex) + + ext4_ext_get_actual_len(nearex + 1)); + if (uninitialized) + ext4_ext_mark_uninitialized(nearex); + if (nearex + 1 < EXT_LAST_EXTENT(eh)) { len = (EXT_LAST_EXTENT(eh) - nearex - 1) * sizeof(struct ext4_extent); @@ -1379,8 +1407,8 @@ int ext4_ext_walk_space(struct inode *in end = le32_to_cpu(ex->ee_block); if (block + num < end) end = block + num; - } else if (block >= - le32_to_cpu(ex->ee_block) + le16_to_cpu(ex->ee_len)) { + } else if (block >= le32_to_cpu(ex->ee_block) + + ext4_ext_get_actual_len(ex)) { /* need to allocate space after found extent */ start = block; end = block + num; @@ -1392,7 +1420,8 @@ int ext4_ext_walk_space(struct inode *in * by found extent */ start = block; - end = le32_to_cpu(ex->ee_block) + le16_to_cpu(ex->ee_len); + end = le32_to_cpu(ex->ee_block) + + ext4_ext_get_actual_len(ex); if (block + num < end) end = block + num; exists = 1; @@ -1408,7 +1437,7 @@ int ext4_ext_walk_space(struct inode *in cbex.ec_type = EXT4_EXT_CACHE_GAP; } else { cbex.ec_block = le32_to_cpu(ex->ee_block); - cbex.ec_len = le16_to_cpu(ex->ee_len); + cbex.ec_len = ext4_ext_get_actual_len(ex); cbex.ec_start = ext_pblock(ex); cbex.ec_type = EXT4_EXT_CACHE_EXTENT; } @@ -1481,15 +1510,15 @@ ext4_ext_put_gap_in_cache(struct inode * ext_debug("cache gap(before): %lu [%lu:%lu]", (unsigned long) block, (unsigned long) le32_to_cpu(ex->ee_block), - (unsigned long) le16_to_cpu(ex->ee_len)); + (unsigned long) ext4_ext_get_actual_len(ex)); } else if (block >= le32_to_cpu(ex->ee_block) - + le16_to_cpu(ex->ee_len)) { + + ext4_ext_get_actual_len(ex)) { lblock = le32_to_cpu(ex->ee_block) - + le16_to_cpu(ex->ee_len); + + ext4_ext_get_actual_len(ex); len = ext4_ext_next_allocated_block(path); ext_debug("cache gap(after): [%lu:%lu] %lu", (unsigned long) le32_to_cpu(ex->ee_block), - (unsigned long) le16_to_cpu(ex->ee_len), + (unsigned long) ext4_ext_get_actual_len(ex), (unsigned long) block); BUG_ON(len == lblock); len = len - lblock; @@ -1619,12 +1648,12 @@ static int ext4_remove_blocks(handle_t * unsigned long from, unsigned long to) { struct buffer_head *bh; + unsigned short ee_len = ext4_ext_get_actual_len(ex); int i; #ifdef EXTENTS_STATS { struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb); - unsigned short ee_len = le16_to_cpu(ex->ee_len); spin_lock(&sbi->s_ext_stats_lock); sbi->s_ext_blocks += ee_len; sbi->s_ext_extents++; @@ -1638,12 +1667,12 @@ static int ext4_remove_blocks(handle_t * } #endif if (from >= le32_to_cpu(ex->ee_block) - && to == le32_to_cpu(ex->ee_block) + le16_to_cpu(ex->ee_len) - 1) { + && to == le32_to_cpu(ex->ee_block) + ee_len - 1) { /* tail removal */ unsigned long num; ext4_fsblk_t start; - num = le32_to_cpu(ex->ee_block) + le16_to_cpu(ex->ee_len) - from; - start = ext_pblock(ex) + le16_to_cpu(ex->ee_len) - num; + num = le32_to_cpu(ex->ee_block) + ee_len - from; + start = ext_pblock(ex) + ee_len - num; ext_debug("free last %lu blocks starting %llu\n", num, start); for (i = 0; i < num; i++) { bh = sb_find_get_block(inode->i_sb, start + i); @@ -1651,12 +1680,12 @@ static int ext4_remove_blocks(handle_t * } ext4_free_blocks(handle, inode, start, num); } else if (from == le32_to_cpu(ex->ee_block) - && to <= le32_to_cpu(ex->ee_block) + le16_to_cpu(ex->ee_len) - 1) { + && to <= le32_to_cpu(ex->ee_block) + ee_len - 1) { printk("strange request: removal %lu-%lu from %u:%u\n", - from, to, le32_to_cpu(ex->ee_block), le16_to_cpu(ex->ee_len)); + from, to, le32_to_cpu(ex->ee_block), ee_len); } else { printk("strange request: removal(2) %lu-%lu from %u:%u\n", - from, to, le32_to_cpu(ex->ee_block), le16_to_cpu(ex->ee_len)); + from, to, le32_to_cpu(ex->ee_block), ee_len); } return 0; } @@ -1671,6 +1700,7 @@ ext4_ext_rm_leaf(handle_t *handle, struc unsigned a, b, block, num; unsigned long ex_ee_block; unsigned short ex_ee_len; + unsigned uninitialized = 0; struct ext4_extent *ex; ext_debug("truncate since %lu in leaf\n", start); @@ -1685,7 +1715,9 @@ ext4_ext_rm_leaf(handle_t *handle, struc ex = EXT_LAST_EXTENT(eh); ex_ee_block = le32_to_cpu(ex->ee_block); - ex_ee_len = le16_to_cpu(ex->ee_len); + if (ext4_ext_is_uninitialized(ex)) + uninitialized = 1; + ex_ee_len = ext4_ext_get_actual_len(ex); while (ex >= EXT_FIRST_EXTENT(eh) && ex_ee_block + ex_ee_len > start) { @@ -1753,6 +1785,8 @@ ext4_ext_rm_leaf(handle_t *handle, struc ex->ee_block = cpu_to_le32(block); ex->ee_len = cpu_to_le16(num); + if (uninitialized) + ext4_ext_mark_uninitialized(ex); err = ext4_ext_dirty(handle, inode, path + depth); if (err) @@ -1762,7 +1796,7 @@ ext4_ext_rm_leaf(handle_t *handle, struc ext_pblock(ex)); ex--; ex_ee_block = le32_to_cpu(ex->ee_block); - ex_ee_len = le16_to_cpu(ex->ee_len); + ex_ee_len = ext4_ext_get_actual_len(ex); } if (correct_index && eh->eh_entries) @@ -2038,7 +2072,7 @@ int ext4_ext_get_blocks(handle_t *handle if (ex) { unsigned long ee_block = le32_to_cpu(ex->ee_block); ext4_fsblk_t ee_start = ext_pblock(ex); - unsigned short ee_len = le16_to_cpu(ex->ee_len); + unsigned short ee_len; /* * Allow future support for preallocated extents to be added @@ -2046,8 +2080,9 @@ int ext4_ext_get_blocks(handle_t *handle * Uninitialized extents are treated as holes, except that * we avoid (fail) allocating new blocks during a write. */ - if (ee_len > EXT_MAX_LEN) + if (le16_to_cpu(ex->ee_len) > EXT_MAX_LEN) goto out2; + ee_len = ext4_ext_get_actual_len(ex); /* if found extent covers block, simply return it */ if (iblock >= ee_block && iblock < ee_block + ee_len) { newblock = iblock - ee_block + ee_start; @@ -2055,8 +2090,11 @@ int ext4_ext_get_blocks(handle_t *handle allocated = ee_len - (iblock - ee_block); ext_debug("%d fit into %lu:%d -> %llu\n", (int) iblock, ee_block, ee_len, newblock); - ext4_ext_put_in_cache(inode, ee_block, ee_len, - ee_start, EXT4_EXT_CACHE_EXTENT); + /* Do not put uninitialized extent in the cache */ + if (!ext4_ext_is_uninitialized(ex)) + ext4_ext_put_in_cache(inode, ee_block, + ee_len, ee_start, + EXT4_EXT_CACHE_EXTENT); goto out; } } @@ -2098,6 +2136,8 @@ int ext4_ext_get_blocks(handle_t *handle /* try to insert new extent into found leaf and return */ ext4_ext_store_pblock(&newex, newblock); newex.ee_len = cpu_to_le16(allocated); + if (create == EXT4_CREATE_UNINITIALIZED_EXT) /* Mark uninitialized */ + ext4_ext_mark_uninitialized(&newex); err = ext4_ext_insert_extent(handle, inode, path, &newex); if (err) { /* free data blocks we just allocated */ @@ -2113,8 +2153,10 @@ int ext4_ext_get_blocks(handle_t *handle newblock = ext_pblock(&newex); __set_bit(BH_New, &bh_result->b_state); - ext4_ext_put_in_cache(inode, iblock, allocated, newblock, - EXT4_EXT_CACHE_EXTENT); + /* Cache only when it is _not_ an uninitialized extent */ + if (create != EXT4_CREATE_UNINITIALIZED_EXT) + ext4_ext_put_in_cache(inode, iblock, allocated, newblock, + EXT4_EXT_CACHE_EXTENT); out: if (allocated > max_blocks) allocated = max_blocks; @@ -2217,3 +2259,129 @@ int ext4_ext_writepage_trans_blocks(stru return needed; } + +/* + * preallocate space for a file. This implements ext4's fallocate inode + * operation, which gets called from sys_fallocate system call. + * Currently only FA_ALLOCATE mode is supported on extent based files. + * We may have more modes supported in future - like FA_DEALLOCATE, which + * tells fallocate to unallocate previously (pre)allocated blocks. + * For block-mapped files, posix_fallocate should fall back to the method + * of writing zeroes to the required new blocks (the same behavior which is + * expected for file systems which do not support fallocate() system call). + */ +long ext4_fallocate(struct inode *inode, int mode, loff_t offset, loff_t len) +{ + handle_t *handle; + ext4_fsblk_t block, max_blocks; + ext4_fsblk_t nblocks = 0; + int ret = 0; + int ret2 = 0; + int retries = 0; + struct buffer_head map_bh; + unsigned int credits, blkbits = inode->i_blkbits; + + /* + * currently supporting (pre)allocate mode for extent-based + * files _only_ + */ + if (mode != FA_ALLOCATE || !(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL)) + return -EOPNOTSUPP; + + /* preallocation to directories is currently not supported */ + if (S_ISDIR(inode->i_mode)) + return -ENODEV; + + block = offset >> blkbits; + max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits) >> blkbits) + - block; + + /* + * credits to insert 1 extent into extent tree + buffers to be able to + * modify 1 super block, 1 block bitmap and 1 group descriptor. + */ + credits = EXT4_DATA_TRANS_BLOCKS(inode->i_sb) + 3; +retry: + while (ret >= 0 && ret < max_blocks) { + block = block + ret; + max_blocks = max_blocks - ret; + handle = ext4_journal_start(inode, credits); + if (IS_ERR(handle)) { + ret = PTR_ERR(handle); + break; + } + + ret = ext4_ext_get_blocks(handle, inode, block, + max_blocks, &map_bh, + EXT4_CREATE_UNINITIALIZED_EXT, 0); + WARN_ON(!ret); + if (!ret) { + ext4_error(inode->i_sb, "ext4_fallocate", + "ext4_ext_get_blocks returned 0! inode#%lu" + ", block=%llu, max_blocks=%llu", + inode->i_ino, block, max_blocks); + ret = -EIO; + ext4_mark_inode_dirty(handle, inode); + ret2 = ext4_journal_stop(handle); + break; + } + if (ret > 0) { + /* check wrap through sign-bit/zero here */ + if ((block + ret) < 0 || (block + ret) < block) { + ret = -EIO; + ext4_mark_inode_dirty(handle, inode); + ret2 = ext4_journal_stop(handle); + break; + } + if (buffer_new(&map_bh) && ((block + ret) > + (EXT4_BLOCK_ALIGN(i_size_read(inode), blkbits) + >> blkbits))) + nblocks = nblocks + ret; + } + + /* Update ctime if new blocks get allocated */ + if (nblocks) { + struct timespec now; + now = current_fs_time(inode->i_sb); + if (!timespec_equal(&inode->i_ctime, &now)) + inode->i_ctime = now; + } + + ext4_mark_inode_dirty(handle, inode); + ret2 = ext4_journal_stop(handle); + if (ret2) + break; + } + + if (ret == -ENOSPC && ext4_should_retry_alloc(inode->i_sb, &retries)) + goto retry; + + /* + * Time to update the file size. + * Update only when preallocation was requested beyond the file size. + */ + if ((offset + len) > i_size_read(inode)) { + if (ret > 0) { + /* + * if no error, we assume preallocation succeeded + * completely + */ + mutex_lock(&inode->i_mutex); + i_size_write(inode, offset + len); + EXT4_I(inode)->i_disksize = i_size_read(inode); + mutex_unlock(&inode->i_mutex); + } else if (ret < 0 && nblocks) { + /* Handle partial allocation scenario */ + loff_t newsize; + + mutex_lock(&inode->i_mutex); + newsize = (nblocks << blkbits) + i_size_read(inode); + i_size_write(inode, EXT4_BLOCK_ALIGN(newsize, blkbits)); + EXT4_I(inode)->i_disksize = i_size_read(inode); + mutex_unlock(&inode->i_mutex); + } + } + + return ret > 0 ? ret2 : ret; +} + Index: linux-2.6.22/fs/ext4/file.c =================================================================== --- linux-2.6.22.orig/fs/ext4/file.c 2007-07-09 15:24:33.000000000 -0700 +++ linux-2.6.22/fs/ext4/file.c 2007-07-09 15:24:39.000000000 -0700 @@ -135,5 +135,6 @@ const struct inode_operations ext4_file_ .removexattr = generic_removexattr, #endif .permission = ext4_permission, + .fallocate = ext4_fallocate, }; Index: linux-2.6.22/include/linux/ext4_fs.h =================================================================== --- linux-2.6.22.orig/include/linux/ext4_fs.h 2007-07-09 15:24:33.000000000 -0700 +++ linux-2.6.22/include/linux/ext4_fs.h 2007-07-09 15:24:39.000000000 -0700 @@ -102,6 +102,7 @@ EXT4_GOOD_OLD_FIRST_INO : \ (s)->s_first_ino) #endif +#define EXT4_BLOCK_ALIGN(size, blkbits) ALIGN((size), (1 << (blkbits))) /* * Macro-instructions used to manage fragments @@ -225,6 +226,11 @@ struct ext4_new_group_data { __u32 free_blocks_count; }; +/* + * Following is used by preallocation code to tell get_blocks() that we + * want uninitialzed extents. + */ +#define EXT4_CREATE_UNINITIALIZED_EXT 2 /* * ioctl commands @@ -983,6 +989,8 @@ extern int ext4_ext_get_blocks(handle_t extern void ext4_ext_truncate(struct inode *, struct page *); extern void ext4_ext_init(struct super_block *); extern void ext4_ext_release(struct super_block *); +extern long ext4_fallocate(struct inode *inode, int mode, loff_t offset, + loff_t len); static inline int ext4_get_blocks_wrap(handle_t *handle, struct inode *inode, sector_t block, unsigned long max_blocks, struct buffer_head *bh, Index: linux-2.6.22/include/linux/ext4_fs_extents.h =================================================================== --- linux-2.6.22.orig/include/linux/ext4_fs_extents.h 2007-07-09 15:24:33.000000000 -0700 +++ linux-2.6.22/include/linux/ext4_fs_extents.h 2007-07-09 15:24:39.000000000 -0700 @@ -188,6 +188,21 @@ ext4_ext_invalidate_cache(struct inode * EXT4_I(inode)->i_cached_extent.ec_type = EXT4_EXT_CACHE_NO; } +static inline void ext4_ext_mark_uninitialized(struct ext4_extent *ext) +{ + ext->ee_len |= cpu_to_le16(0x8000); +} + +static inline int ext4_ext_is_uninitialized(struct ext4_extent *ext) +{ + return (int)(le16_to_cpu((ext)->ee_len) & 0x8000); +} + +static inline int ext4_ext_get_actual_len(struct ext4_extent *ext) +{ + return (int)(le16_to_cpu((ext)->ee_len) & 0x7FFF); +} + extern int ext4_extent_tree_init(handle_t *, struct inode *); extern int ext4_ext_calc_credits_for_insert(struct inode *, struct ext4_ext_path *); extern unsigned int ext4_ext_check_overlap(struct inode *, struct ext4_extent *, struct ext4_ext_path *); From owner-xfs@oss.sgi.com Tue Jul 10 13:24:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 13:24:09 -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.0 required=5.0 tests=AWL,BAYES_95,J_CHICKENPOX_66, J_CHICKENPOX_72 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 l6AKO4bm003259 for ; Tue, 10 Jul 2007 13:24:06 -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 l6AKO5wx002453 for ; Tue, 10 Jul 2007 16:24:05 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6AKO2dl239354 for ; Tue, 10 Jul 2007 14:24:03 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6AKNfEH021121 for ; Tue, 10 Jul 2007 14:23:41 -0600 Received: from amitarora.in.ibm.com ([9.124.94.136]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6AKNcJk020872; Tue, 10 Jul 2007 14:23:38 -0600 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 8941129EB55; Wed, 11 Jul 2007 01:53:53 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6AKNrcr013447; Wed, 11 Jul 2007 01:53:53 +0530 Date: Wed, 11 Jul 2007 01:53:53 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com Subject: [PATCH 5/7] ext4: write support for preallocated blocks Message-ID: <20070710202352.GE8797@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710201200.GA10255@amitarora.in.ibm.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: 12106 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: 11732 Lines: 368 From: Amit Arora write support for preallocated blocks This patch adds write support to the uninitialized extents that get created when a preallocation is done using fallocate(). It takes care of splitting the extents into multiple (upto three) extents and merging the new split extents with neighbouring ones, if possible. Signed-off-by: Amit Arora Index: linux-2.6.22/fs/ext4/extents.c =================================================================== --- linux-2.6.22.orig/fs/ext4/extents.c 2007-07-09 15:24:39.000000000 -0700 +++ linux-2.6.22/fs/ext4/extents.c 2007-07-09 15:24:48.000000000 -0700 @@ -1140,6 +1140,53 @@ ext4_can_extents_be_merged(struct inode } /* + * This function tries to merge the "ex" extent to the next extent in the tree. + * It always tries to merge towards right. If you want to merge towards + * left, pass "ex - 1" as argument instead of "ex". + * Returns 0 if the extents (ex and ex+1) were _not_ merged and returns + * 1 if they got merged. + */ +int ext4_ext_try_to_merge(struct inode *inode, + struct ext4_ext_path *path, + struct ext4_extent *ex) +{ + struct ext4_extent_header *eh; + unsigned int depth, len; + int merge_done = 0; + int uninitialized = 0; + + depth = ext_depth(inode); + BUG_ON(path[depth].p_hdr == NULL); + eh = path[depth].p_hdr; + + while (ex < EXT_LAST_EXTENT(eh)) { + if (!ext4_can_extents_be_merged(inode, ex, ex + 1)) + break; + /* merge with next extent! */ + if (ext4_ext_is_uninitialized(ex)) + uninitialized = 1; + ex->ee_len = cpu_to_le16(ext4_ext_get_actual_len(ex) + + ext4_ext_get_actual_len(ex + 1)); + if (uninitialized) + ext4_ext_mark_uninitialized(ex); + + if (ex + 1 < EXT_LAST_EXTENT(eh)) { + len = (EXT_LAST_EXTENT(eh) - ex - 1) + * sizeof(struct ext4_extent); + memmove(ex + 1, ex + 2, len); + } + eh->eh_entries = cpu_to_le16(le16_to_cpu(eh->eh_entries) - 1); + merge_done = 1; + WARN_ON(eh->eh_entries == 0); + if (!eh->eh_entries) + ext4_error(inode->i_sb, "ext4_ext_try_to_merge", + "inode#%lu, eh->eh_entries = 0!", inode->i_ino); + } + + return merge_done; +} + +/* * check if a portion of the "newext" extent overlaps with an * existing extent. * @@ -1327,25 +1374,7 @@ has_space: merge: /* try to merge extents to the right */ - while (nearex < EXT_LAST_EXTENT(eh)) { - if (!ext4_can_extents_be_merged(inode, nearex, nearex + 1)) - break; - /* merge with next extent! */ - if (ext4_ext_is_uninitialized(nearex)) - uninitialized = 1; - nearex->ee_len = cpu_to_le16(ext4_ext_get_actual_len(nearex) - + ext4_ext_get_actual_len(nearex + 1)); - if (uninitialized) - ext4_ext_mark_uninitialized(nearex); - - if (nearex + 1 < EXT_LAST_EXTENT(eh)) { - len = (EXT_LAST_EXTENT(eh) - nearex - 1) - * sizeof(struct ext4_extent); - memmove(nearex + 1, nearex + 2, len); - } - eh->eh_entries = cpu_to_le16(le16_to_cpu(eh->eh_entries)-1); - BUG_ON(eh->eh_entries == 0); - } + ext4_ext_try_to_merge(inode, path, nearex); /* try to merge extents to the left */ @@ -2011,15 +2040,158 @@ void ext4_ext_release(struct super_block #endif } +/* + * This function is called by ext4_ext_get_blocks() if someone tries to write + * to an uninitialized extent. It may result in splitting the uninitialized + * extent into multiple extents (upto three - one initialized and two + * uninitialized). + * There are three possibilities: + * a> There is no split required: Entire extent should be initialized + * b> Splits in two extents: Write is happening at either end of the extent + * c> Splits in three extents: Somone is writing in middle of the extent + */ +int ext4_ext_convert_to_initialized(handle_t *handle, struct inode *inode, + struct ext4_ext_path *path, + ext4_fsblk_t iblock, + unsigned long max_blocks) +{ + struct ext4_extent *ex, newex; + struct ext4_extent *ex1 = NULL; + struct ext4_extent *ex2 = NULL; + struct ext4_extent *ex3 = NULL; + struct ext4_extent_header *eh; + unsigned int allocated, ee_block, ee_len, depth; + ext4_fsblk_t newblock; + int err = 0; + int ret = 0; + + depth = ext_depth(inode); + eh = path[depth].p_hdr; + ex = path[depth].p_ext; + ee_block = le32_to_cpu(ex->ee_block); + ee_len = ext4_ext_get_actual_len(ex); + allocated = ee_len - (iblock - ee_block); + newblock = iblock - ee_block + ext_pblock(ex); + ex2 = ex; + + /* ex1: ee_block to iblock - 1 : uninitialized */ + if (iblock > ee_block) { + ex1 = ex; + ex1->ee_len = cpu_to_le16(iblock - ee_block); + ext4_ext_mark_uninitialized(ex1); + ex2 = &newex; + } + /* + * for sanity, update the length of the ex2 extent before + * we insert ex3, if ex1 is NULL. This is to avoid temporary + * overlap of blocks. + */ + if (!ex1 && allocated > max_blocks) + ex2->ee_len = cpu_to_le16(max_blocks); + /* ex3: to ee_block + ee_len : uninitialised */ + if (allocated > max_blocks) { + unsigned int newdepth; + ex3 = &newex; + ex3->ee_block = cpu_to_le32(iblock + max_blocks); + ext4_ext_store_pblock(ex3, newblock + max_blocks); + ex3->ee_len = cpu_to_le16(allocated - max_blocks); + ext4_ext_mark_uninitialized(ex3); + err = ext4_ext_insert_extent(handle, inode, path, ex3); + if (err) + goto out; + /* + * The depth, and hence eh & ex might change + * as part of the insert above. + */ + newdepth = ext_depth(inode); + if (newdepth != depth) { + depth = newdepth; + path = ext4_ext_find_extent(inode, iblock, NULL); + if (IS_ERR(path)) { + err = PTR_ERR(path); + path = NULL; + goto out; + } + eh = path[depth].p_hdr; + ex = path[depth].p_ext; + if (ex2 != &newex) + ex2 = ex; + } + allocated = max_blocks; + } + /* + * If there was a change of depth as part of the + * insertion of ex3 above, we need to update the length + * of the ex1 extent again here + */ + if (ex1 && ex1 != ex) { + ex1 = ex; + ex1->ee_len = cpu_to_le16(iblock - ee_block); + ext4_ext_mark_uninitialized(ex1); + ex2 = &newex; + } + /* ex2: iblock to iblock + maxblocks-1 : initialised */ + ex2->ee_block = cpu_to_le32(iblock); + ex2->ee_start = cpu_to_le32(newblock); + ext4_ext_store_pblock(ex2, newblock); + ex2->ee_len = cpu_to_le16(allocated); + if (ex2 != ex) + goto insert; + err = ext4_ext_get_access(handle, inode, path + depth); + if (err) + goto out; + /* + * New (initialized) extent starts from the first block + * in the current extent. i.e., ex2 == ex + * We have to see if it can be merged with the extent + * on the left. + */ + if (ex2 > EXT_FIRST_EXTENT(eh)) { + /* + * To merge left, pass "ex2 - 1" to try_to_merge(), + * since it merges towards right _only_. + */ + ret = ext4_ext_try_to_merge(inode, path, ex2 - 1); + if (ret) { + err = ext4_ext_correct_indexes(handle, inode, path); + if (err) + goto out; + depth = ext_depth(inode); + ex2--; + } + } + /* + * Try to Merge towards right. This might be required + * only when the whole extent is being written to. + * i.e. ex2 == ex and ex3 == NULL. + */ + if (!ex3) { + ret = ext4_ext_try_to_merge(inode, path, ex2); + if (ret) { + err = ext4_ext_correct_indexes(handle, inode, path); + if (err) + goto out; + } + } + /* Mark modified extent as dirty */ + err = ext4_ext_dirty(handle, inode, path + depth); + goto out; +insert: + err = ext4_ext_insert_extent(handle, inode, path, &newex); +out: + return err ? err : allocated; +} + int ext4_ext_get_blocks(handle_t *handle, struct inode *inode, ext4_fsblk_t iblock, unsigned long max_blocks, struct buffer_head *bh_result, int create, int extend_disksize) { struct ext4_ext_path *path = NULL; + struct ext4_extent_header *eh; struct ext4_extent newex, *ex; ext4_fsblk_t goal, newblock; - int err = 0, depth; + int err = 0, depth, ret; unsigned long allocated = 0; __clear_bit(BH_New, &bh_result->b_state); @@ -2032,8 +2204,10 @@ int ext4_ext_get_blocks(handle_t *handle if (goal) { if (goal == EXT4_EXT_CACHE_GAP) { if (!create) { - /* block isn't allocated yet and - * user doesn't want to allocate it */ + /* + * block isn't allocated yet and + * user doesn't want to allocate it + */ goto out2; } /* we should allocate requested block */ @@ -2067,6 +2241,7 @@ int ext4_ext_get_blocks(handle_t *handle * this is why assert can't be put in ext4_ext_find_extent() */ BUG_ON(path[depth].p_ext == NULL && depth != 0); + eh = path[depth].p_hdr; ex = path[depth].p_ext; if (ex) { @@ -2075,13 +2250,9 @@ int ext4_ext_get_blocks(handle_t *handle unsigned short ee_len; /* - * Allow future support for preallocated extents to be added - * as an RO_COMPAT feature: * Uninitialized extents are treated as holes, except that - * we avoid (fail) allocating new blocks during a write. + * we split out initialized portions during a write. */ - if (le16_to_cpu(ex->ee_len) > EXT_MAX_LEN) - goto out2; ee_len = ext4_ext_get_actual_len(ex); /* if found extent covers block, simply return it */ if (iblock >= ee_block && iblock < ee_block + ee_len) { @@ -2090,12 +2261,27 @@ int ext4_ext_get_blocks(handle_t *handle allocated = ee_len - (iblock - ee_block); ext_debug("%d fit into %lu:%d -> %llu\n", (int) iblock, ee_block, ee_len, newblock); + /* Do not put uninitialized extent in the cache */ - if (!ext4_ext_is_uninitialized(ex)) + if (!ext4_ext_is_uninitialized(ex)) { ext4_ext_put_in_cache(inode, ee_block, ee_len, ee_start, EXT4_EXT_CACHE_EXTENT); - goto out; + goto out; + } + if (create == EXT4_CREATE_UNINITIALIZED_EXT) + goto out; + if (!create) + goto out2; + + ret = ext4_ext_convert_to_initialized(handle, inode, + path, iblock, + max_blocks); + if (ret <= 0) + goto out2; + else + allocated = ret; + goto outnew; } } @@ -2104,8 +2290,10 @@ int ext4_ext_get_blocks(handle_t *handle * we couldn't try to create block if create flag is zero */ if (!create) { - /* put just found gap into cache to speed up - * subsequent requests */ + /* + * put just found gap into cache to speed up + * subsequent requests + */ ext4_ext_put_gap_in_cache(inode, path, iblock); goto out2; } @@ -2151,6 +2339,7 @@ int ext4_ext_get_blocks(handle_t *handle /* previous routine could use block we allocated */ newblock = ext_pblock(&newex); +outnew: __set_bit(BH_New, &bh_result->b_state); /* Cache only when it is _not_ an uninitialized extent */ @@ -2220,7 +2409,8 @@ void ext4_ext_truncate(struct inode * in err = ext4_ext_remove_space(inode, last_block); /* In a multi-transaction truncate, we only make the final - * transaction synchronous. */ + * transaction synchronous. + */ if (IS_SYNC(inode)) handle->h_sync = 1; Index: linux-2.6.22/include/linux/ext4_fs_extents.h =================================================================== --- linux-2.6.22.orig/include/linux/ext4_fs_extents.h 2007-07-09 15:24:39.000000000 -0700 +++ linux-2.6.22/include/linux/ext4_fs_extents.h 2007-07-09 15:24:48.000000000 -0700 @@ -205,6 +205,9 @@ static inline int ext4_ext_get_actual_le extern int ext4_extent_tree_init(handle_t *, struct inode *); extern int ext4_ext_calc_credits_for_insert(struct inode *, struct ext4_ext_path *); +extern int ext4_ext_try_to_merge(struct inode *inode, + struct ext4_ext_path *path, + struct ext4_extent *); extern unsigned int ext4_ext_check_overlap(struct inode *, struct ext4_extent *, struct ext4_ext_path *); extern int ext4_ext_insert_extent(handle_t *, struct inode *, struct ext4_ext_path *, struct ext4_extent *); extern int ext4_ext_walk_space(struct inode *, unsigned long, unsigned long, ext_prepare_callback, void *); From owner-xfs@oss.sgi.com Tue Jul 10 13:24:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 13:24: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=0.4 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6AKOWbm003544 for ; Tue, 10 Jul 2007 13:24:33 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6AJKiCi005902 for ; Tue, 10 Jul 2007 15:20:44 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6AKORc3311456 for ; Tue, 10 Jul 2007 16:24:27 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6AKORbq006488 for ; Tue, 10 Jul 2007 16:24:27 -0400 Received: from amitarora.in.ibm.com ([9.124.94.136]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6AKOQrD006425; Tue, 10 Jul 2007 16:24:27 -0400 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id D165429EB55; Wed, 11 Jul 2007 01:54:41 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6AKOf4p013900; Wed, 11 Jul 2007 01:54:41 +0530 Date: Wed, 11 Jul 2007 01:54:41 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com Subject: [PATCH 6/7] ext4: support new modes in ext4 Message-ID: <20070710202441.GF8797@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710201200.GA10255@amitarora.in.ibm.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: 12107 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: 2211 Lines: 51 From: Amit Arora Support new values of mode in ext4. This patch supports new mode values/flags in ext4. With this patch ext4 will be able to support FALLOC_ALLOCATE and FALLOC_RESV_SPACE modes. Supporting FALLOC_DEALLOCATE and FALLOC_UNRESV_SPACE fallocate modes in ext4 is a work for future. Signed-off-by: Amit Arora Index: linux-2.6.22/fs/ext4/extents.c =================================================================== --- linux-2.6.22.orig/fs/ext4/extents.c +++ linux-2.6.22/fs/ext4/extents.c @@ -2453,8 +2453,9 @@ int ext4_ext_writepage_trans_blocks(stru /* * preallocate space for a file. This implements ext4's fallocate inode * operation, which gets called from sys_fallocate system call. - * Currently only FA_ALLOCATE mode is supported on extent based files. - * We may have more modes supported in future - like FA_DEALLOCATE, which + * Currently only FALLOC_ALLOCATE and FALLOC_RESV_SPACE modes are supported on + * extent based files. + * We may have more modes supported in future - like FALLOC_DEALLOCATE, which * tells fallocate to unallocate previously (pre)allocated blocks. * For block-mapped files, posix_fallocate should fall back to the method * of writing zeroes to the required new blocks (the same behavior which is @@ -2475,7 +2476,8 @@ long ext4_fallocate(struct inode *inode, * currently supporting (pre)allocate mode for extent-based * files _only_ */ - if (mode != FA_ALLOCATE || !(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL)) + if (!(EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL) || + !(mode == FALLOC_ALLOCATE || mode == FALLOC_RESV_SPACE)) return -EOPNOTSUPP; /* preallocation to directories is currently not supported */ @@ -2548,9 +2550,11 @@ retry: /* * Time to update the file size. - * Update only when preallocation was requested beyond the file size. + * Update only when preallocation was requested beyond the file size + * and when FALLOC_FL_KEEP_SIZE mode is not specified! */ - if ((offset + len) > i_size_read(inode)) { + if (!(mode & FALLOC_FL_KEEP_SIZE) && + (offset + len) > i_size_read(inode)) { if (ret > 0) { /* * if no error, we assume preallocation succeeded From owner-xfs@oss.sgi.com Tue Jul 10 13:25:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 13:26:03 -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.9 required=5.0 tests=AWL,BAYES_60 autolearn=no version=3.2.0-pre1-r499012 Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6AKPubm004434 for ; Tue, 10 Jul 2007 13:25:57 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6AKPwSQ004145 for ; Tue, 10 Jul 2007 16:25:58 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6AKPpvH200770 for ; Tue, 10 Jul 2007 14:25:52 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6AKPotE031258 for ; Tue, 10 Jul 2007 14:25:50 -0600 Received: from amitarora.in.ibm.com ([9.124.94.136]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6AKPnhk031157; Tue, 10 Jul 2007 14:25:49 -0600 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 8E77529EB55; Wed, 11 Jul 2007 01:56:04 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6AKQ407014692; Wed, 11 Jul 2007 01:56:04 +0530 Date: Wed, 11 Jul 2007 01:56:03 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com Subject: [PATCH 7/7] ext4: change for better extent-to-group alignment Message-ID: <20070710202603.GG8797@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710201200.GA10255@amitarora.in.ibm.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: 12108 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: 5452 Lines: 138 From: Amit Arora Change on-disk format for extent to represent uninitialized/initialized extents This change was suggested by Andreas Dilger as part of the following post: http://www.mail-archive.com/linux-ext4@vger.kernel.org/msg02445.html This patch changes the EXT_MAX_LEN value and extent code which marks/checks uninitialized extents. With this change it will be possible to have initialized extents with 2^15 blocks (earlier the max blocks we could have was 2^15 - 1). This way we can have better extent-to-block alignment. Now, maximum number of blocks we can have in an initialized extent is 2^15 and in an uninitialized extent is 2^15 - 1. Signed-off-by: Amit Arora Index: linux-2.6.22/fs/ext4/extents.c =================================================================== --- linux-2.6.22.orig/fs/ext4/extents.c +++ linux-2.6.22/fs/ext4/extents.c @@ -1106,7 +1106,7 @@ static int ext4_can_extents_be_merged(struct inode *inode, struct ext4_extent *ex1, struct ext4_extent *ex2) { - unsigned short ext1_ee_len, ext2_ee_len; + unsigned short ext1_ee_len, ext2_ee_len, max_len; /* * Make sure that either both extents are uninitialized, or @@ -1115,6 +1115,11 @@ ext4_can_extents_be_merged(struct inode if (ext4_ext_is_uninitialized(ex1) ^ ext4_ext_is_uninitialized(ex2)) return 0; + if (ext4_ext_is_uninitialized(ex1)) + max_len = EXT_UNINIT_MAX_LEN; + else + max_len = EXT_INIT_MAX_LEN; + ext1_ee_len = ext4_ext_get_actual_len(ex1); ext2_ee_len = ext4_ext_get_actual_len(ex2); @@ -1127,7 +1132,7 @@ ext4_can_extents_be_merged(struct inode * as an RO_COMPAT feature, refuse to merge to extents if * this can result in the top bit of ee_len being set. */ - if (ext1_ee_len + ext2_ee_len > EXT_MAX_LEN) + if (ext1_ee_len + ext2_ee_len > max_len) return 0; #ifdef AGGRESSIVE_TEST if (le16_to_cpu(ex1->ee_len) >= 4) @@ -1814,7 +1819,11 @@ ext4_ext_rm_leaf(handle_t *handle, struc ex->ee_block = cpu_to_le32(block); ex->ee_len = cpu_to_le16(num); - if (uninitialized) + /* + * Do not mark uninitialized if all the blocks in the + * extent have been removed. + */ + if (uninitialized && num) ext4_ext_mark_uninitialized(ex); err = ext4_ext_dirty(handle, inode, path + depth); @@ -2307,6 +2316,18 @@ int ext4_ext_get_blocks(handle_t *handle /* allocate new block */ goal = ext4_ext_find_goal(inode, path, iblock); + /* + * See if request is beyond maximum number of blocks we can have in + * a single extent. For an initialized extent this limit is + * EXT_INIT_MAX_LEN and for an uninitialized extent this limit is + * EXT_UNINIT_MAX_LEN. + */ + if (max_blocks > EXT_INIT_MAX_LEN && create != EXT4_CREATE_UNINITIALIZED_EXT) + max_blocks = EXT_INIT_MAX_LEN; + else if (max_blocks > EXT_UNINIT_MAX_LEN && + create == EXT4_CREATE_UNINITIALIZED_EXT) + max_blocks = EXT_UNINIT_MAX_LEN; + /* Check if we can really insert (iblock)::(iblock+max_blocks) extent */ newex.ee_block = cpu_to_le32(iblock); newex.ee_len = cpu_to_le16(max_blocks); Index: linux-2.6.22/include/linux/ext4_fs_extents.h =================================================================== --- linux-2.6.22.orig/include/linux/ext4_fs_extents.h +++ linux-2.6.22/include/linux/ext4_fs_extents.h @@ -141,7 +141,25 @@ typedef int (*ext_prepare_callback)(stru #define EXT_MAX_BLOCK 0xffffffff -#define EXT_MAX_LEN ((1UL << 15) - 1) +/* + * EXT_INIT_MAX_LEN is the maximum number of blocks we can have in an + * initialized extent. This is 2^15 and not (2^16 - 1), since we use the + * MSB of ee_len field in the extent datastructure to signify if this + * particular extent is an initialized extent or an uninitialized (i.e. + * preallocated). + * EXT_UNINIT_MAX_LEN is the maximum number of blocks we can have in an + * uninitialized extent. + * If ee_len is <= 0x8000, it is an initialized extent. Otherwise, it is an + * uninitialized one. In other words, if MSB of ee_len is set, it is an + * uninitialized extent with only one special scenario when ee_len = 0x8000. + * In this case we can not have an uninitialized extent of zero length and + * thus we make it as a special case of initialized extent with 0x8000 length. + * This way we get better extent-to-group alignment for initialized extents. + * Hence, the maximum number of blocks we can have in an *initialized* + * extent is 2^15 (32768) and in an *uninitialized* extent is 2^15-1 (32767). + */ +#define EXT_INIT_MAX_LEN (1UL << 15) +#define EXT_UNINIT_MAX_LEN (EXT_INIT_MAX_LEN - 1) #define EXT_FIRST_EXTENT(__hdr__) \ @@ -190,17 +208,21 @@ ext4_ext_invalidate_cache(struct inode * static inline void ext4_ext_mark_uninitialized(struct ext4_extent *ext) { + /* We can not have an uninitialized extent of zero length! */ + BUG_ON((le16_to_cpu(ext->ee_len) & ~0x8000) == 0); ext->ee_len |= cpu_to_le16(0x8000); } static inline int ext4_ext_is_uninitialized(struct ext4_extent *ext) { - return (int)(le16_to_cpu((ext)->ee_len) & 0x8000); + /* Extent with ee_len of 0x8000 is treated as an initialized extent */ + return (le16_to_cpu(ext->ee_len) > 0x8000); } static inline int ext4_ext_get_actual_len(struct ext4_extent *ext) { - return (int)(le16_to_cpu((ext)->ee_len) & 0x7FFF); + return (le16_to_cpu(ext->ee_len) <= 0x8000 ? le16_to_cpu(ext->ee_len) : + (le16_to_cpu(ext->ee_len) - 0x8000)); } extern int ext4_extent_tree_init(handle_t *, struct inode *); From owner-xfs@oss.sgi.com Tue Jul 10 14:26:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 14: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=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6ALQrbm018709 for ; Tue, 10 Jul 2007 14:26:53 -0700 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 101F2908A5 for ; Tue, 10 Jul 2007 14:08:30 -0700 (PDT) Received: from [128.162.233.117] (augusta.americas.sgi.com [128.162.233.117]) by estes.americas.sgi.com (Postfix) with ESMTP id 0D7817000103; Tue, 10 Jul 2007 15:15:59 -0500 (CDT) Message-ID: <4693E877.4090409@sgi.com> Date: Tue, 10 Jul 2007 15:13:43 -0500 From: Bill Kendall User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Jakob Praher Cc: linux-xfs@oss.sgi.com Subject: Re: usage pattern: xfsrestore to mirror disks References: <4691C1BA.4040603@sgi.com> <4693DCD6.2010106@hapra.at> In-Reply-To: <4693DCD6.2010106@hapra.at> 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: 12109 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 499 Lines: 29 Hi Jakob, If I'm understanding your issue correctly, it sounds like rsync would be a good tool for your needs. Or is there some reason you're not using rsync? Bill On 07/10/2007 02:24 PM, Jakob Praher wrote: > Hi Timothy, > > thanks for your quick response. > I will apply your patch and try it out. > > Timothy Shimmin wrote: >> Hi Jakob, >> >> I wonder if other tools might be useful to you... xfscopy,...? >> > that would be very interesting for me. > > -- Jakob >> --Tim >> >> > >> > From owner-xfs@oss.sgi.com Tue Jul 10 14:56:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 14:56:28 -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=BAYES_50,J_CHICKENPOX_63, J_CHICKENPOX_73 autolearn=no version=3.2.0-pre1-r499012 Received: from zakalwe.fi (zakalwe.fi [80.83.5.154]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6ALuNbm025362 for ; Tue, 10 Jul 2007 14:56:24 -0700 Received: by zakalwe.fi (Postfix, from userid 1023) id 9E0E42BF60; Wed, 11 Jul 2007 00:37:01 +0300 (EEST) Date: Wed, 11 Jul 2007 00:37:01 +0300 From: Heikki Orsila To: "Amit K. Arora" Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH 1/7] manpage for fallocate Message-ID: <20070710213701.GG3400@zakalwe.fi> References: <20070710201200.GA10255@amitarora.in.ibm.com> <20070710201820.GA8797@amitarora.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20070710201820.GA8797@amitarora.in.ibm.com> User-Agent: Mutt/1.5.11 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12110 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: shdl@zakalwe.fi Precedence: bulk X-list: xfs Status: O Content-Length: 890 Lines: 44 On Wed, Jul 11, 2007 at 01:48:20AM +0530, Amit K. Arora wrote: > .BI "int syscall(int, int fd, int mode, loff_t offset, loff_t len); Correction: "int syscall(int fd, int mode, ...)", > .SH "ERRORS" > .TP > .B EBADF > .I fd > is not a valid file descriptor, or is not opened for writing. > .TP > .B EFBIG > .I offset+len > exceeds the maximum file size. > .TP > .B EINVAL > .I offset > or > .I len > was less than 0. > .TP > .B ENODEV > .I fd > does not refer to a regular file or a directory. > .TP > .B ENOSPC > There is not enough space left on the device containing the file > referred to by > .IR fd. > .TP > .B ESPIPE > .I fd > refers to a pipe of file descriptor. > .B ENOSYS > The filesystem underlying the file descriptor does not support this > operation. EINTR? -- Heikki Orsila Barbie's law: heikki.orsila@iki.fi "Math is hard, let's go shopping!" http://www.iki.fi/shd From owner-xfs@oss.sgi.com Tue Jul 10 18:34:45 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 18:34: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.3 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 l6B1Yfbm011542 for ; Tue, 10 Jul 2007 18:34:43 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17668; Wed, 11 Jul 2007 11:34:32 +1000 To: "Amit K. Arora" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH 1/7] manpage for fallocate From: "Barry Naujok" Organization: SGI Cc: xfs@oss.sgi.com Content-Type: multipart/mixed; boundary=----------WTbI0GSzrQq8swZHzkUhcQ MIME-Version: 1.0 References: <20070710201200.GA10255@amitarora.in.ibm.com> <20070710201820.GA8797@amitarora.in.ibm.com> Date: Wed, 11 Jul 2007 11:37:45 +1000 Message-ID: In-Reply-To: <20070710201820.GA8797@amitarora.in.ibm.com> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12111 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 4472 Lines: 85 ------------WTbI0GSzrQq8swZHzkUhcQ Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit On Wed, 11 Jul 2007 06:18:20 +1000, Amit K. Arora wrote: > Following is the modified version of the manpage originally submitted by > David Chinner. Please use `nroff -man fallocate.2 | less` to view. A few more touch-ups attached. Regards, Barry. ------------WTbI0GSzrQq8swZHzkUhcQ Content-Disposition: attachment; filename=fallocate.2 Content-Type: application/octet-stream; name=fallocate.2 Content-Transfer-Encoding: Base64 LlRIIGZhbGxvY2F0ZSAyCi5TSCBOQU1FCmZhbGxvY2F0ZSBcLSBhbGxvY2F0 ZSBvciByZW1vdmUgZmlsZSBzcGFjZQouU0ggU1lOT1BTSVMKLkIgI2luY2x1 ZGUgPHN5cy9zeXNjYWxsLmg+Ci5QUAouQkkgImludCBzeXNjYWxsKGludCwg aW50ICIgZmQgIiwgaW50ICIgbW9kZSAiLCBsb2ZmX3QgIiBvZmZzZXQgIiwg bG9mZl90ICIgbGVuICk7Ci5TSCBERVNDUklQVElPTgpUaGUKLkIgZmFsbG9j YXRlCnN5c2NhbGwgYWxsb3dzIGEgdXNlciB0byBkaXJlY3RseSBtYW5pcHVs YXRlIHRoZSBhbGxvY2F0ZWQgZGlzayBzcGFjZQpmb3IgdGhlIGZpbGUgcmVm ZXJyZWQgdG8gYnkKLkkgZmQKZm9yIHRoZSBieXRlIHJhbmdlIHN0YXJ0aW5n IGF0Ci5JIG9mZnNldAphbmQgY29udGludWluZyBmb3IKLkkgbGVuCmJ5dGVz LgpUaGUKLkkgbW9kZQpwYXJhbWV0ZXIgZGV0ZXJtaW5lcyB0aGUgb3BlcmF0 aW9uIHRvIGJlIHBlcmZvcm1lZCBvbiB0aGUgZ2l2ZW4gcmFuZ2UuCkN1cnJl bnRseSB0aGVyZSBhcmUgZm91ciBtb2RlczoKLlRQCi5CIEZBTExPQ19BTExP Q0FURQphbGxvY2F0ZXMgYW5kIGluaXRpYWxpc2VzIHRvIHplcm8gdGhlIGRp c2sgc3BhY2Ugd2l0aGluIHRoZSBnaXZlbiByYW5nZS4KQWZ0ZXIgYSBzdWNj ZXNzZnVsIGNhbGwsIHN1YnNlcXVlbnQgd3JpdGVzIGFyZSBndWFyYW50ZWVk IG5vdCB0byBmYWlsIGJlY2F1c2UKb2YgbGFjayBvZiBkaXNrIHNwYWNlLiAg SWYgdGhlIHNpemUgb2YgdGhlIGZpbGUgaXMgbGVzcyB0aGFuCi5JUiBvZmZz ZXQgKyBsZW4gLAp0aGVuIHRoZSBmaWxlIGlzIGluY3JlYXNlZCB0byB0aGlz IHNpemU7IG90aGVyd2lzZSB0aGUgZmlsZSBzaXplIGlzIGxlZnQKdW5jaGFu Z2VkLgouQiBGQUxMT0NfQUxMT0NBVEUKY2xvc2VseSByZXNlbWJsZXMKLkJS IHBvc2l4X2ZhbGxvY2F0ZSAoMykKYW5kIGlzIGludGVuZGVkIGFzIGEgbWV0 aG9kIG9mIG9wdGltYWxseSBpbXBsZW1lbnRpbmcgdGhpcyBmdW5jdGlvbi4K LkIgRkFMTE9DX0FMTE9DQVRFCm1heSBhbGxvY2F0ZSBhIGxhcmdlciByYW5n ZSB0aGF0IHdhcyBzcGVjaWZpZWQuCi5UUAouQiBGQUxMT0NfUkVTVl9TUEFD RQpwcm92aWRlcyB0aGUgc2FtZSBmdW5jdGlvbmFsaXR5IGFzCi5CIEZBTExP Q19BTExPQ0FURQpleGNlcHQgaXQgZG9lcyBub3QgZXZlciBjaGFuZ2UgdGhl IGZpbGUgc2l6ZS4gVGhpcyBhbGxvd3MgYWxsb2NhdGlvbgpvZiB6ZXJvIGJs b2NrcyBiZXlvbmQgdGhlIGVuZCBvZiBmaWxlIGFuZCBpcyB1c2VmdWwgZm9y IG9wdGltaXNpbmcKYXBwZW5kIHdvcmtsb2Fkcy4KLlRQCi5CIEZBTExPQ19E RUFMTE9DQVRFCnJlbW92ZXMgYW55IHByZWFsbG9jYXRlZCBzcGFjZSB3aXRo aW4gdGhlIGdpdmVuIHJhbmdlLiBUaGUgZmlsZSBzaXplCm1heSBjaGFuZ2Ug aWYgZGVhbGxvY2F0aW9uIGlzIHRvd2FyZHMgdGhlIGVuZCBvZiB0aGUgZmls ZS4KLlRQCi5CIEZBTExPQ19VTlJFU1ZfU1BBQ0UKcmVtb3ZlcyB0aGUgdW5k ZXJseWluZyBkaXNrIHNwYWNlIHdpdGhpbiB0aGUgZ2l2ZW4gcmFuZ2UuIFRo ZSBkaXNrIHNwYWNlCnNoYWxsIGJlIHJlbW92ZWQgcmVnYXJkbGVzcyBvZiBp dCdzIGNvbnRlbnRzIHNvIGJvdGggYWxsb2NhdGVkIHNwYWNlCmZyb20KLkIg RkFMTE9DX0FMTE9DQVRFCmFuZAouQiBGQUxMT0NfUkVTVl9TUEFDRQphcyB3 ZWxsIGFzIGZyb20KLkJSIHdyaXRlICgzKQp3aWxsIGJlIHJlbW92ZWQuCi5C IEZBTExPQ19VTlJFU1ZfU1BBQ0UKc2hhbGwgbmV2ZXIgcmVtb3ZlIGRpc2sg YmxvY2tzIG91dHNpZGUgdGhlIHJhbmdlIHNwZWNpZmllZC4KLkIgRkFMTE9D X1VOUkVTVl9TUEFDRQpzaGFsbCBuZXZlciBjaGFuZ2UgdGhlIGZpbGUgc2l6 ZS4gSWYgY2hhbmdpbmcgdGhlIGZpbGUgc2l6ZQppcyByZXF1aXJlZCB3aGVu IGRlYWxsb2NhdGluZyBibG9ja3MgZnJvbSBhbiBvZmZzZXQgdG8gZW5kCm9m IGZpbGUgKG9yIGJleW9uZCBlbmQgb2YgZmlsZSkgaXMgcmVxdWlyZWQsCi5C UiBmdHVuY2F0ZTY0ICgzKQpvcgouQiBGQUxMT0NfREVBTExPQ0FURQpzaG91 bGQgYmUgdXNlZC4KCi5TSCBSRVRVUk4gVkFMVUUKLkIgZmFsbG9jYXRlCnJl dHVybnMgemVybyBvbiBzdWNjZXNzLCBvciBhbiBlcnJvciBudW1iZXIgb24g ZmFpbHVyZS4KTm90ZSB0aGF0Ci5JIGVycm5vCmlzIG5vdCBzZXQuCi5TSCBF UlJPUlMKLlRQCi5CIEVCQURGCi5JIGZkCmlzIG5vdCBhIHZhbGlkIGZpbGUg ZGVzY3JpcHRvciwgb3IgaXMgbm90IG9wZW5lZCBmb3Igd3JpdGluZy4KLlRQ Ci5CIEVGQklHCi5JUiBvZmZzZXQgKyBsZW4KZXhjZWVkcyB0aGUgbWF4aW11 bSBmaWxlIHNpemUuCi5UUAouQiBFSU5WQUwKLkkgb2Zmc2V0Cm9yCi5JIGxl bgp3YXMgbGVzcyB0aGFuIDAuCi5UUAouQiBFTk9ERVYKLkkgZmQKZG9lcyBu b3QgcmVmZXIgdG8gYSByZWd1bGFyIGZpbGUgb3IgYSBkaXJlY3RvcnkuCi5U UAouQiBFTk9TUEMKVGhlcmUgaXMgbm90IGVub3VnaCBzcGFjZSBsZWZ0IG9u IHRoZSBkZXZpY2UgY29udGFpbmluZyB0aGUgZmlsZQpyZWZlcnJlZCB0byBi eQouSVIgZmQgLgouVFAKLkIgRVNQSVBFCi5JIGZkCnJlZmVycyB0byBhIHBp cGUgb2YgZmlsZSBkZXNjcmlwdG9yLgouVFAKLkIgRU5PU1lTClRoZSBmaWxl c3lzdGVtIHVuZGVybHlpbmcgdGhlIGZpbGUgZGVzY3JpcHRvciBkb2VzIG5v dCBzdXBwb3J0IHRoaXMKb3BlcmF0aW9uLgouU0ggQVZBSUxBQklMSVRZClRo ZQouQiBmYWxsb2NhdGUKc3lzdGVtIGNhbGwgaXMgYXZhaWxhYmxlIHNpbmNl IDIuNi5YWAouU0ggU0VFIEFMU08KLkJSIHN5c2NhbGwgKDIpLAouQlIgcG9z aXhfZmFkdmlzZSAoMyksCi5CUiBmdHJ1bmNhdGUgKDMpLgo= ------------WTbI0GSzrQq8swZHzkUhcQ-- From owner-xfs@oss.sgi.com Tue Jul 10 19:35:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 19:35:47 -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.0 required=5.0 tests=BAYES_50,URIBL_RHS_TLD_WHOIS autolearn=no version=3.2.0-pre1-r499012 Received: from smtps.tip.net.au (chilli.pcug.org.au [203.10.76.44]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6B2Zfbm026915 for ; Tue, 10 Jul 2007 19:35:43 -0700 Received: from localhost (bh02i525f01.au.ibm.com [202.81.18.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by smtps.tip.net.au (Postfix) with ESMTP id C1982368005; Wed, 11 Jul 2007 12:10:31 +1000 (EST) Date: Wed, 11 Jul 2007 12:10:34 +1000 From: Stephen Rothwell To: "Amit K. Arora" Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH 2/7] fallocate() implementation in i386, x86_64 and powerpc Message-Id: <20070711121034.a3b925b9.sfr@canb.auug.org.au> In-Reply-To: <20070710202000.GB8797@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> <20070710202000.GB8797@amitarora.in.ibm.com> X-Mailer: Sylpheed 2.4.3 (GTK+ 2.10.13; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__11_Jul_2007_12_10_34_+1000_5U2tHjshZm6024bl" X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12112 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sfr@canb.auug.org.au Precedence: bulk X-list: xfs Status: O Content-Length: 1374 Lines: 42 --Signature=_Wed__11_Jul_2007_12_10_34_+1000_5U2tHjshZm6024bl Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 11 Jul 2007 01:50:00 +0530 "Amit K. Arora" wrote: > > --- linux-2.6.22.orig/arch/x86_64/ia32/sys_ia32.c > +++ linux-2.6.22/arch/x86_64/ia32/sys_ia32.c > @@ -879,3 +879,11 @@ asmlinkage long sys32_fadvise64(int fd,=20 > return sys_fadvise64_64(fd, ((u64)offset_hi << 32) | offset_lo, > len, advice); > } > + > +asmlinkage long sys32_fallocate(int fd, int mode, unsigned offset_lo, > + unsigned offset_hi, unsigned len_lo, > + unsigned len_hi) Please call this compat_sys_fallocate in line with the powerpc version - it gives us a hint that maybe we should think about how to consolidate them. I know other stuff in that file is called sys32_ ... but it is time for a change :-) --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ --Signature=_Wed__11_Jul_2007_12_10_34_+1000_5U2tHjshZm6024bl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGlDweTgG2atn1QN8RAsMWAJ0QGe/B34/KjrV593lYeDo/VsOYdQCfdMkc mHS8nJDyRZd1RWYTVZ+6888= =C6vS -----END PGP SIGNATURE----- --Signature=_Wed__11_Jul_2007_12_10_34_+1000_5U2tHjshZm6024bl-- From owner-xfs@oss.sgi.com Tue Jul 10 20:14:33 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 20:14: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.3 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 l6B3EUbm004601 for ; Tue, 10 Jul 2007 20:14:32 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA20148; Wed, 11 Jul 2007 13:14:31 +1000 Date: Wed, 11 Jul 2007 13:18:20 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: REVIEW: fix xfs_bmap -vp confusion From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------5g2s3VDJlM5DkZKD2Ny1cP MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12113 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 2277 Lines: 46 ------------5g2s3VDJlM5DkZKD2Ny1cP Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit If xfs_bmap -vp is run on a file without unwritten extents and the filesystem does not use sunit/swidth, the FLAGS column is not shown. This leads to some confusion. So, when -vp option is used, it will always print the FLAGS column. ------------5g2s3VDJlM5DkZKD2Ny1cP Content-Disposition: attachment; filename=xfs_bmap_pflag.patch Content-Type: application/octet-stream; name=xfs_bmap_pflag.patch Content-Transfer-Encoding: Base64 LS0tIGEveGZzcHJvZ3MvaW8vYm1hcC5jCTIwMDctMDctMTEgMTM6MTE6NDIu MDAwMDAwMDAwICsxMDAwCisrKyBiL3hmc3Byb2dzL2lvL2JtYXAuYwkyMDA3 LTA3LTExIDEyOjM0OjMzLjUxOTU3MjcwOSArMTAwMApAQCAtNzQsNiArNzQs NyBAQCBibWFwX2YoCiAJaW50CQkJYWZsYWcgPSAwOwogCWludAkJCWxmbGFn ID0gMDsKIAlpbnQJCQluZmxhZyA9IDA7CisJaW50CQkJcGZsYWcgPSAwOwog CWludAkJCXZmbGFnID0gMDsKIAlpbnQJCQlpc19ydCA9IDA7CiAJaW50CQkJ Ym12X2lmbGFncyA9IDA7CS8qIGZsYWdzIGZvciBYRlNfSU9DX0dFVEJNQVBY ICovCkBAIC05OSw2ICsxMDAsNyBAQCBibWFwX2YoCiAJCQlicmVhazsKIAkJ Y2FzZSAncCc6CiAJCS8qIHJlcG9ydCB1bndyaXR0ZW4gcHJlYWxsb2NhdGVk IGJsb2NrcyAqLworCQkJcGZsYWcgPSAxOwogCQkJYm12X2lmbGFncyB8PSBC TVZfSUZfUFJFQUxMT0M7CiAJCQlicmVhazsKIAkJY2FzZSAndic6CS8qIFZl cmJvc2Ugb3V0cHV0ICovCkBAIC0yODksNyArMjkxLDcgQEAgYm1hcF9mKAog CQkJc3VuaXQgPSAoZnNnZW8uc3VuaXQgKiBmc2dlby5ibG9ja3NpemUpIC8g QkJTSVpFOwogCQkJc3dpZHRoID0gKGZzZ2VvLnN3aWR0aCAqIGZzZ2VvLmJs b2Nrc2l6ZSkgLyBCQlNJWkU7CiAJCX0KLQkJZmxnID0gc3VuaXQ7CisJCWZs ZyA9IHN1bml0IHwgcGZsYWc7CiAKIAkJLyoKIAkJICogR28gdGhyb3VnaCB0 aGUgZXh0ZW50cyBhbmQgZmlndXJlIG91dCB0aGUgd2lkdGgKQEAgLTM5Nywx NCArMzk5LDE0IEBAIGJtYXBfZigKIAkJCQkJcHJpbnRmKCIgICIpOwogCQkJ CXByaW50ZigiICUqbGxkIiwgdG90X3csCiAJCQkJCShsb25nIGxvbmcpbWFw W2krMV0uYm12X2xlbmd0aCk7Ci0JCQkJaWYgKGZsZyA9PSBGTEdfTlVMTCkg eworCQkJCWlmIChmbGcgPT0gRkxHX05VTEwgJiYgIXBmbGFnKSB7CiAJCQkJ CXByaW50ZigiXG4iKTsKIAkJCQl9IGVsc2UgewogCQkJCQlwcmludGYoIiAl LSouKm9cbiIsIE5GTEcsIE5GTEcsIGZsZyk7CiAJCQkJfQogCQkJfQogCQl9 Ci0JCWlmIChmbGcgJiYgdmZsYWcgPiAxKSB7CisJCWlmICgoZmxnIHx8IHBm bGFnKSAmJiB2ZmxhZyA+IDEpIHsKIAkJCXByaW50ZihfKCIgRkxBRyBWYWx1 ZXM6XG4iKSk7CiAJCQlwcmludGYoXygiICAgICUqLipvIFVud3JpdHRlbiBw cmVhbGxvY2F0ZWQgZXh0ZW50XG4iKSwKIAkJCQlORkxHKzEsIE5GTEcrMSwg RkxHX1BSRSk7Cg== ------------5g2s3VDJlM5DkZKD2Ny1cP-- From owner-xfs@oss.sgi.com Tue Jul 10 22:00:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 22:00: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=0.1 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from mtagate7.de.ibm.com (mtagate7.de.ibm.com [195.212.29.156]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6B503bm007374 for ; Tue, 10 Jul 2007 22:00:04 -0700 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id l6B502FY098876 for ; Wed, 11 Jul 2007 05:00:02 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6B502fs1986646 for ; Wed, 11 Jul 2007 07:00:02 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6B501At000602 for ; Wed, 11 Jul 2007 07:00:02 +0200 Received: from localhost (ICON-9-164-164-121.megacenter.de.ibm.com [9.164.164.121]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6B501lW000519; Wed, 11 Jul 2007 07:00:01 +0200 Date: Wed, 11 Jul 2007 06:59:58 +0200 From: Heiko Carstens To: Stephen Rothwell Cc: "Amit K. Arora" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH 2/7] fallocate() implementation in i386, x86_64 and powerpc Message-ID: <20070711045958.GA12843@osiris.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> <20070710202000.GB8797@amitarora.in.ibm.com> <20070711121034.a3b925b9.sfr@canb.auug.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711121034.a3b925b9.sfr@canb.auug.org.au> User-Agent: mutt-ng/devel-r804 (Linux) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12114 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: heiko.carstens@de.ibm.com Precedence: bulk X-list: xfs Status: O Content-Length: 938 Lines: 25 On Wed, Jul 11, 2007 at 12:10:34PM +1000, Stephen Rothwell wrote: > On Wed, 11 Jul 2007 01:50:00 +0530 "Amit K. Arora" wrote: > > > > --- linux-2.6.22.orig/arch/x86_64/ia32/sys_ia32.c > > +++ linux-2.6.22/arch/x86_64/ia32/sys_ia32.c > > @@ -879,3 +879,11 @@ asmlinkage long sys32_fadvise64(int fd, > > return sys_fadvise64_64(fd, ((u64)offset_hi << 32) | offset_lo, > > len, advice); > > } > > + > > +asmlinkage long sys32_fallocate(int fd, int mode, unsigned offset_lo, > > + unsigned offset_hi, unsigned len_lo, > > + unsigned len_hi) > > Please call this compat_sys_fallocate in line with the powerpc version - > it gives us a hint that maybe we should think about how to consolidate > them. I know other stuff in that file is called sys32_ ... but it is time > for a change :-) Maybe it would be worth to finally consider this: http://marc.info/?l=linux-kernel&m=118411511620432&w=2 ? From owner-xfs@oss.sgi.com Tue Jul 10 22:53:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 22:53: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.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 l6B5rqbm025977 for ; Tue, 10 Jul 2007 22:53:54 -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 PAA24618; Wed, 11 Jul 2007 15:53:49 +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 l6B5rneW19613240; Wed, 11 Jul 2007 15:53:49 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6B5rmsq19641382; Wed, 11 Jul 2007 15:53:48 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 11 Jul 2007 15:53:47 +1000 From: David Chinner To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: fix xfs_bmap -vp confusion Message-ID: <20070711055347.GP12413810@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12115 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: 631 Lines: 21 On Wed, Jul 11, 2007 at 01:18:20PM +1000, Barry Naujok wrote: > If xfs_bmap -vp is run on a file without unwritten extents > and the filesystem does not use sunit/swidth, the FLAGS > column is not shown. This leads to some confusion. > > So, when -vp option is used, it will always print the > FLAGS column. I note that it only prints the legend if a flag is set. I guess this is ok, but maybe it would be more consistent to always print the legend? Or even to make the legend optional (which would make dumping more than one file more compact)? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Jul 10 22:56:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 22:56: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=0.3 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 l6B5uSbm027050 for ; Tue, 10 Jul 2007 22:56:30 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA24693; Wed, 11 Jul 2007 15:56:30 +1000 Date: Wed, 11 Jul 2007 16:00:13 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: REVIEW: Improve xfs_io and xfs_quota -c handling From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------wbndoKBep6ZtqAMfwrEJYW MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12116 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 8443 Lines: 147 ------------wbndoKBep6ZtqAMfwrEJYW Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit xfs_io and xfs_quota's -c option handling is not very good for "global" commands which don't rely on the file/filesystem list it uses. Command such as "help" and "print" are such candidates. The attached patch addresses this issue, and also allows "-c help [xxx]" in xfs_io without a file. xfs_quota will not print help once for each XFS filesystem either. ------------wbndoKBep6ZtqAMfwrEJYW Content-Disposition: attachment; filename=fix_c_option.patch Content-Type: application/octet-stream; name=fix_c_option.patch Content-Transfer-Encoding: Base64 Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNwcm9ncy9pbmNs dWRlL2NvbW1hbmQuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K Ci0tLSBhL3hmc3Byb2dzL2luY2x1ZGUvY29tbWFuZC5oCTIwMDctMDctMTEg MTU6NTI6MzUuMDAwMDAwMDAwICsxMDAwCisrKyBiL3hmc3Byb2dzL2luY2x1 ZGUvY29tbWFuZC5oCTIwMDctMDctMTEgMTU6NTI6MjYuODYxNjQ2NTUyICsx MDAwCkBAIC0xOCw2ICsxOCw4IEBACiAjaWZuZGVmIF9fQ09NTUFORF9IX18K ICNkZWZpbmUgX19DT01NQU5EX0hfXwogCisjZGVmaW5lIENNRF9GTEFHX0dM T0JBTAkoKGludCkweDgwMDAwMDAwKQkvKiBkb24ndCBpdGVyYXRlICJhcmdz IiAqLworCiB0eXBlZGVmIGludCAoKmNmdW5jX3QpKGludCBhcmdjLCBjaGFy ICoqYXJndik7CiB0eXBlZGVmIHZvaWQgKCpoZWxwZnVuY190KSh2b2lkKTsK IApAQCAtNTIsNiArNTQsNiBAQCBleHRlcm4gY29uc3QgY21kaW5mb190CSpm aW5kX2NvbW1hbmQoY29uCiAKIGV4dGVybiB2b2lkCQljb21tYW5kX2xvb3Ao dm9pZCk7CiBleHRlcm4gaW50CQljb21tYW5kX3VzYWdlKGNvbnN0IGNtZGlu Zm9fdCAqY2kpOwotZXh0ZXJuIGludAkJY29tbWFuZChpbnQgYXJnYywgY2hh ciAqKmFyZ3YpOworZXh0ZXJuIGludAkJY29tbWFuZChjb25zdCBjbWRpbmZv X3QgKmNpLCBpbnQgYXJnYywgY2hhciAqKmFyZ3YpOwogCiAjZW5kaWYJLyog X19DT01NQU5EX0hfXyAqLwoKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Cnhmc3Byb2dzL2lvL2ZpbGUuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KCi0tLSBhL3hmc3Byb2dzL2lvL2ZpbGUuYwkyMDA3LTA3LTEx IDE1OjUyOjM1LjAwMDAwMDAwMCArMTAwMAorKysgYi94ZnNwcm9ncy9pby9m aWxlLmMJMjAwNy0wNy0xMSAxNTozNzo1Mi41NDgyODg4MDkgKzEwMDAKQEAg LTEwMyw3ICsxMDMsOCBAQCBmaWxlX2luaXQodm9pZCkKIAlwcmludF9jbWQu Y2Z1bmMgPSBwcmludF9mOwogCXByaW50X2NtZC5hcmdtaW4gPSAwOwogCXBy aW50X2NtZC5hcmdtYXggPSAwOwotCXByaW50X2NtZC5mbGFncyA9IENNRF9O T01BUF9PSyB8IENNRF9OT0ZJTEVfT0sgfCBDTURfRk9SRUlHTl9PSzsKKwlw cmludF9jbWQuZmxhZ3MgPSBDTURfTk9NQVBfT0sgfCBDTURfTk9GSUxFX09L IHwgQ01EX0ZPUkVJR05fT0sgfAorCQkJCUNNRF9GTEFHX0dMT0JBTDsKIAlw cmludF9jbWQub25lbGluZSA9IF8oImxpc3QgY3VycmVudCBvcGVuIGZpbGVz IGFuZCBtZW1vcnkgbWFwcGluZ3MiKTsKIAogCWFkZF9jb21tYW5kKCZmaWxl X2NtZCk7Cgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KeGZzcHJv Z3MvbGlieGNtZC9jb21tYW5kLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09CgotLS0gYS94ZnNwcm9ncy9saWJ4Y21kL2NvbW1hbmQuYwkyMDA3 LTA3LTExIDE1OjUyOjM1LjAwMDAwMDAwMCArMTAwMAorKysgYi94ZnNwcm9n cy9saWJ4Y21kL2NvbW1hbmQuYwkyMDA3LTA3LTExIDE1OjM4OjUwLjg0ODYz NTk3OSArMTAwMApAQCAtNzAsMjAgKzcwLDE1IEBAIGNvbW1hbmRfdXNhZ2Uo CiAKIGludAogY29tbWFuZCgKKwljb25zdCBjbWRpbmZvX3QJKmN0LAogCWlu dAkJYXJnYywKIAljaGFyCQkqKmFyZ3YpCiB7Ci0JY2hhcgkJKmNtZDsKLQlj b25zdCBjbWRpbmZvX3QJKmN0OworCWNoYXIJCSpjbWQgPSBhcmd2WzBdOwog Ci0JY21kID0gYXJndlswXTsKLQljdCA9IGZpbmRfY29tbWFuZChjbWQpOwot CWlmICghY3QpIHsKLQkJZnByaW50ZihzdGRlcnIsIF8oImNvbW1hbmQgXCIl c1wiIG5vdCBmb3VuZFxuIiksIGNtZCk7Ci0JCXJldHVybiAwOwotCX0KIAlp ZiAoIWNoZWNrX2NvbW1hbmQoY3QpKQogCQlyZXR1cm4gMDsKKwogCWlmIChh cmdjLTEgPCBjdC0+YXJnbWluIHx8IChjdC0+YXJnbWF4ICE9IC0xICYmIGFy Z2MtMSA+IGN0LT5hcmdtYXgpKSB7CiAJCWlmIChjdC0+YXJnbWF4ID09IC0x KQogCQkJZnByaW50ZihzdGRlcnIsCkBAIC0xNDgsMjYgKzE0MywzNSBAQCBh ZGRfYXJnc19jb21tYW5kKAogdm9pZAogY29tbWFuZF9sb29wKHZvaWQpCiB7 Ci0JaW50CWMsIGksIGogPSAwLCBkb25lID0gMDsKLQljaGFyCSppbnB1dDsK LQljaGFyCSoqdjsKKwlpbnQJCWMsIGksIGogPSAwLCBkb25lID0gMDsKKwlj aGFyCQkqaW5wdXQ7CisJY2hhcgkJKip2OworCWNvbnN0IGNtZGluZm9fdAkq Y3Q7CiAKIAlmb3IgKGkgPSAwOyAhZG9uZSAmJiBpIDwgbmNtZGxpbmU7IGkr KykgewotCQl3aGlsZSAoIWRvbmUgJiYgKGogPSBhcmdzX2NvbW1hbmQoaikp KSB7Ci0JCQlpbnB1dCA9IHN0cmR1cChjbWRsaW5lW2ldKTsKLQkJCWlmICgh aW5wdXQpIHsKLQkJCQlmcHJpbnRmKHN0ZGVyciwKLQkJCQkJXygiY2Fubm90 IHN0cmR1cCBjb21tYW5kICclcyc6ICVzXG4iKSwKLQkJCQkJY21kbGluZVtp XSwgc3RyZXJyb3IoZXJybm8pKTsKLQkJCQlleGl0KDEpOwotCQkJfQotCQkJ diA9IGJyZWFrbGluZShpbnB1dCwgJmMpOwotCQkJaWYgKGMpCi0JCQkJZG9u ZSA9IGNvbW1hbmQoYywgdik7Ci0JCQlmcmVlKHYpOwotCQkJZnJlZShpbnB1 dCk7CisJCWlucHV0ID0gc3RyZHVwKGNtZGxpbmVbaV0pOworCQlpZiAoIWlu cHV0KSB7CisJCQlmcHJpbnRmKHN0ZGVyciwKKwkJCQlfKCJjYW5ub3Qgc3Ry ZHVwIGNvbW1hbmQgJyVzJzogJXNcbiIpLAorCQkJCWNtZGxpbmVbaV0sIHN0 cmVycm9yKGVycm5vKSk7CisJCQlleGl0KDEpOworCQl9CisJCXYgPSBicmVh a2xpbmUoaW5wdXQsICZjKTsKKwkJaWYgKGMpIHsKKwkJCWN0ID0gZmluZF9j b21tYW5kKHZbMF0pOworCQkJaWYgKGN0KSB7CisJCQkJaWYgKGN0LT5mbGFn cyAmIENNRF9GTEFHX0dMT0JBTCkKKwkJCQkJZG9uZSA9IGNvbW1hbmQoY3Qs IGMsIHYpOworCQkJCWVsc2UgeworCQkJCQlqID0gMDsKKwkJCQkJd2hpbGUg KCFkb25lICYmIChqID0gYXJnc19jb21tYW5kKGopKSkKKwkJCQkJCWRvbmUg PSBjb21tYW5kKGN0LCBjLCB2KTsKKwkJCQl9CisJCQl9IGVsc2UKKwkJCQlm cHJpbnRmKHN0ZGVyciwgXygiY29tbWFuZCBcIiVzXCIgbm90IGZvdW5kXG4i KSwKKwkJCQkJdlswXSk7CiAJCX0KLQkJaiA9IDA7CS8qIHJlc2V0ICovCisJ CWRvbmVsaW5lKGlucHV0LCB2KTsKIAl9CiAJaWYgKGNtZGxpbmUpIHsKIAkJ ZnJlZShjbWRsaW5lKTsKQEAgLTE3Nyw4ICsxODEsMTQgQEAgY29tbWFuZF9s b29wKHZvaWQpCiAJCWlmICgoaW5wdXQgPSBmZXRjaGxpbmUoKSkgPT0gTlVM TCkKIAkJCWJyZWFrOwogCQl2ID0gYnJlYWtsaW5lKGlucHV0LCAmYyk7Ci0J CWlmIChjKQotCQkJZG9uZSA9IGNvbW1hbmQoYywgdik7CisJCWlmIChjKSB7 CisJCQljdCA9IGZpbmRfY29tbWFuZCh2WzBdKTsKKwkJCWlmIChjdCkKKwkJ CQlkb25lID0gY29tbWFuZChjdCwgYywgdik7CisJCQllbHNlCisJCQkJZnBy aW50ZihzdGRlcnIsIF8oImNvbW1hbmQgXCIlc1wiIG5vdCBmb3VuZFxuIiks CisJCQkJCXZbMF0pOworCQl9CiAJCWRvbmVsaW5lKGlucHV0LCB2KTsKIAl9 CiB9Cgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KeGZzcHJvZ3Mv bGlieGNtZC9oZWxwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 CgotLS0gYS94ZnNwcm9ncy9saWJ4Y21kL2hlbHAuYwkyMDA3LTA3LTExIDE1 OjUyOjM1LjAwMDAwMDAwMCArMTAwMAorKysgYi94ZnNwcm9ncy9saWJ4Y21k L2hlbHAuYwkyMDA3LTA3LTExIDE1OjM4OjIwLjQzMjYyODQ1OSArMTAwMApA QCAtODgsNyArODgsNyBAQCBoZWxwX2luaXQodm9pZCkKIAloZWxwX2NtZC5j ZnVuYyA9IGhlbHBfZjsKIAloZWxwX2NtZC5hcmdtaW4gPSAwOwogCWhlbHBf Y21kLmFyZ21heCA9IDE7Ci0JaGVscF9jbWQuZmxhZ3MgPSAtMTsKKwloZWxw X2NtZC5mbGFncyA9IENNRF9GTEFHX0dMT0JBTDsKIAloZWxwX2NtZC5hcmdz ID0gXygiW2NvbW1hbmRdIik7CiAJaGVscF9jbWQub25lbGluZSA9IF8oImhl bHAgZm9yIG9uZSBvciBhbGwgY29tbWFuZHMiKTsKIAoKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Cnhmc3Byb2dzL2xpYnhjbWQvcXVpdC5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKLS0tIGEveGZzcHJvZ3Mv bGlieGNtZC9xdWl0LmMJMjAwNy0wNy0xMSAxNTo1MjozNS4wMDAwMDAwMDAg KzEwMDAKKysrIGIveGZzcHJvZ3MvbGlieGNtZC9xdWl0LmMJMjAwNy0wNy0x MSAxNTo0MjoxNC40MDU5MjE3NzggKzEwMDAKQEAgLTM4LDcgKzM4LDcgQEAg cXVpdF9pbml0KHZvaWQpCiAJcXVpdF9jbWQuY2Z1bmMgPSBxdWl0X2Y7CiAJ cXVpdF9jbWQuYXJnbWluID0gLTE7CiAJcXVpdF9jbWQuYXJnbWF4ID0gLTE7 Ci0JcXVpdF9jbWQuZmxhZ3MgPSAtMTsKKwlxdWl0X2NtZC5mbGFncyA9IENN RF9GTEFHX0dMT0JBTDsKIAlxdWl0X2NtZC5vbmVsaW5lID0gXygiZXhpdCB0 aGUgcHJvZ3JhbSIpOwogCiAJYWRkX2NvbW1hbmQoJnF1aXRfY21kKTsKCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNwcm9ncy9xdW90YS9w YXRoLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgotLS0gYS94 ZnNwcm9ncy9xdW90YS9wYXRoLmMJMjAwNy0wNy0xMSAxNTo1MjozNS4wMDAw MDAwMDAgKzEwMDAKKysrIGIveGZzcHJvZ3MvcXVvdGEvcGF0aC5jCTIwMDct MDctMTEgMTU6NDE6NTAuNTQ5MDUyMjE0ICsxMDAwCkBAIC0xMjIsNiArMTIy LDcgQEAgcGF0aF9pbml0KHZvaWQpCiAJcGF0aF9jbWQuY2Z1bmMgPSBwYXRo X2Y7CiAJcGF0aF9jbWQuYXJnbWluID0gMDsKIAlwYXRoX2NtZC5hcmdtYXgg PSAxOworCXBhdGhfY21kLmZsYWdzID0gQ01EX0ZMQUdfR0xPQkFMOwogCXBh dGhfY21kLm9uZWxpbmUgPSBfKCJzZXQgY3VycmVudCBwYXRoLCBvciBzaG93 IHRoZSBsaXN0IG9mIHBhdGhzIik7CiAKIAlwcmludF9jbWQubmFtZSA9IF8o InByaW50Iik7CkBAIC0xMjksNiArMTMwLDcgQEAgcGF0aF9pbml0KHZvaWQp CiAJcHJpbnRfY21kLmNmdW5jID0gcHJpbnRfZjsKIAlwcmludF9jbWQuYXJn bWluID0gMDsKIAlwcmludF9jbWQuYXJnbWF4ID0gMDsKKwlwcmludF9jbWQu ZmxhZ3MgPSBDTURfRkxBR19HTE9CQUw7CiAJcHJpbnRfY21kLm9uZWxpbmUg PSBfKCJsaXN0IGtub3duIG1vdW50IHBvaW50cyBhbmQgcHJvamVjdHMiKTsK IAogCWlmIChleHBlcnQpCg== ------------wbndoKBep6ZtqAMfwrEJYW-- From owner-xfs@oss.sgi.com Tue Jul 10 23:00:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 23:00:32 -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 l6B60Mbm028975 for ; Tue, 10 Jul 2007 23:00:24 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24921; Wed, 11 Jul 2007 16:00:20 +1000 Date: Wed, 11 Jul 2007 16:04:05 +1000 To: "David Chinner" Subject: Re: REVIEW: fix xfs_bmap -vp confusion From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" , xfs-dev Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <20070711055347.GP12413810@sgi.com> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20070711055347.GP12413810@sgi.com> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12117 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 1064 Lines: 31 On Wed, 11 Jul 2007 15:53:47 +1000, David Chinner wrote: > On Wed, Jul 11, 2007 at 01:18:20PM +1000, Barry Naujok wrote: >> If xfs_bmap -vp is run on a file without unwritten extents >> and the filesystem does not use sunit/swidth, the FLAGS >> column is not shown. This leads to some confusion. >> >> So, when -vp option is used, it will always print the >> FLAGS column. > > I note that it only prints the legend if a flag is set. I guess > this is ok, but maybe it would be more consistent to always > print the legend? Or even to make the legend optional (which > would make dumping more than one file more compact)? > > Cheers, > > Dave. The legend* is only shown with an extra -v option and the FLAGS column displayed. The updated man pages posted out yesterday documents this. * I assume the legend you refer to is: FLAG Values: 010000 Unwritten preallocated extent 001000 Doesn't begin on stripe unit 000100 Doesn't end on stripe unit 000010 Doesn't begin on stripe width 000001 Doesn't end on stripe width From owner-xfs@oss.sgi.com Tue Jul 10 23:18:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jul 2007 23:18: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.1 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6B6IYbm003081 for ; Tue, 10 Jul 2007 23:18:35 -0700 Received: from edge.yarra.acx (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 73171123C1DC; Wed, 11 Jul 2007 16:18:36 +1000 (EST) Subject: Re: REVIEW: Improve xfs_io and xfs_quota -c handling From: Nathan Scott Reply-To: nscott@aconex.com To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev In-Reply-To: References: Content-Type: text/plain Organization: Aconex Date: Wed, 11 Jul 2007 16:18:06 +1000 Message-Id: <1184134686.15488.498.camel@edge.yarra.acx> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 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: 12118 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Status: O Content-Length: 274 Lines: 13 On Wed, 2007-07-11 at 16:00 +1000, Barry Naujok wrote: > > The attached patch addresses this issue, and also allows > "-c help [xxx]" in xfs_io without a file. xfs_quota will > not print help once for each XFS filesystem either. Looks alright to me. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jul 11 01:06:03 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 01:06:06 -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 l6B85xbm009430 for ; Wed, 11 Jul 2007 01:06: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 SAA28525; Wed, 11 Jul 2007 18:05:57 +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 l6B85ueW19713847; Wed, 11 Jul 2007 18:05:56 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6B85tdT18364543; Wed, 11 Jul 2007 18:05:55 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 11 Jul 2007 18:05:55 +1000 From: David Chinner To: Barry Naujok Cc: David Chinner , "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: fix xfs_bmap -vp confusion Message-ID: <20070711080555.GS12413810@sgi.com> References: <20070711055347.GP12413810@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: 12119 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: 1067 Lines: 39 On Wed, Jul 11, 2007 at 04:04:05PM +1000, Barry Naujok wrote: > On Wed, 11 Jul 2007 15:53:47 +1000, David Chinner wrote: > > >On Wed, Jul 11, 2007 at 01:18:20PM +1000, Barry Naujok wrote: > >>If xfs_bmap -vp is run on a file without unwritten extents > >>and the filesystem does not use sunit/swidth, the FLAGS > >>column is not shown. This leads to some confusion. > >> > >>So, when -vp option is used, it will always print the > >>FLAGS column. > > > >I note that it only prints the legend if a flag is set. I guess > >this is ok, but maybe it would be more consistent to always > >print the legend? Or even to make the legend optional (which > >would make dumping more than one file more compact)? > > > >Cheers, > > > >Dave. > > The legend* is only shown with an extra -v option and the FLAGS > column displayed. Ah, that'd be the > 1 check. Looks good then.... > The updated man pages posted out yesterday documents this. I haven't had time to read them yet. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Jul 11 01:11:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 01: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=0.4 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6B8BPbm011422 for ; Wed, 11 Jul 2007 01:11:26 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6B8BSop022451 for ; Wed, 11 Jul 2007 04:11:28 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6B8BRBw423710 for ; Wed, 11 Jul 2007 04:11:27 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6B8BRxh022347 for ; Wed, 11 Jul 2007 04:11:27 -0400 Received: from amitarora.in.ibm.com ([9.124.31.198]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6B8BQWi022265; Wed, 11 Jul 2007 04:11:27 -0400 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id E7FED29F6BB; Wed, 11 Jul 2007 13:41:42 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6B8Bfue028470; Wed, 11 Jul 2007 13:41:41 +0530 Date: Wed, 11 Jul 2007 13:41:41 +0530 From: "Amit K. Arora" To: Stephen Rothwell Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH 2/7] fallocate() implementation in i386, x86_64 and powerpc Message-ID: <20070711081141.GA25383@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> <20070710202000.GB8797@amitarora.in.ibm.com> <20070711121034.a3b925b9.sfr@canb.auug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070711121034.a3b925b9.sfr@canb.auug.org.au> 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: 12120 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: 1025 Lines: 28 On Wed, Jul 11, 2007 at 12:10:34PM +1000, Stephen Rothwell wrote: > On Wed, 11 Jul 2007 01:50:00 +0530 "Amit K. Arora" wrote: > > > > --- linux-2.6.22.orig/arch/x86_64/ia32/sys_ia32.c > > +++ linux-2.6.22/arch/x86_64/ia32/sys_ia32.c > > @@ -879,3 +879,11 @@ asmlinkage long sys32_fadvise64(int fd, > > return sys_fadvise64_64(fd, ((u64)offset_hi << 32) | offset_lo, > > len, advice); > > } > > + > > +asmlinkage long sys32_fallocate(int fd, int mode, unsigned offset_lo, > > + unsigned offset_hi, unsigned len_lo, > > + unsigned len_hi) > > Please call this compat_sys_fallocate in line with the powerpc version - > it gives us a hint that maybe we should think about how to consolidate > them. I know other stuff in that file is called sys32_ ... but it is time > for a change :-) I think this can be handled as a separate patch once this patchset is in mainline. Since, anyhow we will need to do this for other sys32_ calls which are already there... -- Regards, Amit Arora From owner-xfs@oss.sgi.com Wed Jul 11 01:37:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 01:37: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.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 l6B8brbm019758 for ; Wed, 11 Jul 2007 01:37:55 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA29609; Wed, 11 Jul 2007 18:37:47 +1000 Date: Wed, 11 Jul 2007 18:41:24 +1000 To: "Utako Kusaka" Subject: Re: REVIEW: Updated all xfsprogs man pages From: "Barry Naujok" Organization: SGI Cc: xfs-dev , "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <200707110834.AA05713@TNESG9305.wm.jp.nec.com> Message-ID: In-Reply-To: <200707110834.AA05713@TNESG9305.wm.jp.nec.com> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l6B8bubm019804 X-archive-position: 12121 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 374 Lines: 16 On Wed, 11 Jul 2007 18:34:14 +1000, Utako Kusaka wrote: > Hi, > I sent a patch more than one month ago but it is not included in your > patch. > Should I update my patch based on your patch and resend? > http://marc.info/?l=linux-xfs&m=118050289805766&w=4 Hi, I'll incorporate your patch into mine. Thanks for reminding me. Regards, Barry. From owner-xfs@oss.sgi.com Wed Jul 11 02:03:40 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 02:03:43 -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,J_CHICKENPOX_43, J_CHICKENPOX_56 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 l6B93abm029038 for ; Wed, 11 Jul 2007 02:03:38 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA00458; Wed, 11 Jul 2007 19:03:38 +1000 Date: Wed, 11 Jul 2007 19:07:24 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: REVIEW: zero existing secondary superblocks with mkfs.xfs -f From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------1bmT4AjRtp81ALP1nN5vGp MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12122 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 12024 Lines: 217 ------------1bmT4AjRtp81ALP1nN5vGp Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: Quoted-Printable The attached patch zeros all the secondary superblocks if overwriting an existing XFS filesystem. This allows xfs_repair to detect the correct secondary block if the primary is destroyed (like XFS QA test 030). To demonstrate the bad behaviour, try the following: # mkfs.xfs -f /dev/xxx ... [note agcount reported] # dd if=3D/dev/zero of=3D/dev/xxx oflag=3Ddirect bs=3D512 count=3D1 # xfs_repair /dev/xxx ... (it should recover and a second repair will succeed.) # mkfs.xfs -f -d agcount=3D /dev/xxx ... # dd if=3D/dev/zero of=3D/dev/xxx oflag=3Ddirect bs=3D512 count=3D1 # xfs_repair /dev/xxx It will either die or succeed (in my test, xfs_repair actually crashed because it doesn't handle bad extents yet!). If success, try and mount it and run: # xfs_info /dev/xxx (It should be the geometry of the first mkfs run.) Try the patch and repeat - success.= ------------1bmT4AjRtp81ALP1nN5vGp Content-Disposition: attachment; filename=mkfs_zero_old_ags.patch Content-Type: application/octet-stream; name=mkfs_zero_old_ags.patch Content-Transfer-Encoding: Base64 LS0tIGEveGZzcHJvZ3MvbWtmcy94ZnNfbWtmcy5jCTIwMDctMDctMTEgMTg6 NTI6NTUuMDAwMDAwMDAwICsxMDAwCisrKyBiL3hmc3Byb2dzL21rZnMveGZz X21rZnMuYwkyMDA3LTA3LTExIDE4OjUxOjQxLjQ4NDY2ODgwMiArMTAwMApA QCAtNDEyLDcgKzQxMiw3IEBAIGNhbGNfZGVmYXVsdF9hZ19nZW9tZXRyeSgK IAkgKiBiYXNlZCBvbiB0aGUgcHJlZmVyZWQgQUcgc2l6ZSwgbm90IHZpY2Ut dmVyc2EgLSB0aGUKIAkgKiBjb3VudCBjYW4gYmUgaW5jcmVhc2VkIGJ5IGdy b3dmcywgc28gcHJlZmVyIHRvIHVzZQogCSAqIHNtYWxsZXIgY291bnRzIGF0 IG1rZnMgdGltZS4KLQkgKiAKKwkgKgogCSAqIFRoaXMgc2NhbGVzIHVzIHVw IHNtb290aGx5IGJldHdlZW4gbWluL21heCBBRyBzaXplcy4KIAkgKi8KIAlp ZiAoZGJsb2NrcyA+IEdJR0FCWVRFUyg1MTIsIGJsb2NrbG9nKSkKQEAgLTQ3 Nyw3ICs0NzcsNyBAQCB2YWxpZGF0ZV9hZ19nZW9tZXRyeSgKIAlfKCJ0b28g ZmV3IGFsbG9jYXRpb24gZ3JvdXBzIGZvciBzaXplID0gJWxsZFxuIiksIChs b25nIGxvbmcpYWdzaXplKTsKIAkJZnByaW50ZihzdGRlcnIsCiAJXygibmVl ZCBhdCBsZWFzdCAlbGxkIGFsbG9jYXRpb24gZ3JvdXBzXG4iKSwKLQkJKGxv bmcgbG9uZykoZGJsb2NrcyAvIFhGU19BR19NQVhfQkxPQ0tTKGJsb2NrbG9n KSArIAorCQkobG9uZyBsb25nKShkYmxvY2tzIC8gWEZTX0FHX01BWF9CTE9D S1MoYmxvY2tsb2cpICsKIAkJCShkYmxvY2tzICUgWEZTX0FHX01BWF9CTE9D S1MoYmxvY2tsb2cpICE9IDApKSk7CiAJCXVzYWdlKCk7CiAJfQpAQCAtNTA2 LDYgKzUwNiw3MCBAQCB2YWxpZGF0ZV9hZ19nZW9tZXRyeSgKIAl9CiB9CiAK K3N0YXRpYyB2b2lkCit6ZXJvX29sZF94ZnNfc3RydWN0dXJlcygKKwlsaWJ4 ZnNfaW5pdF90CQkqeGksCisJaW50CQkJc2VjdHNpemUpCit7CisJdm9pZCAJ CQkqYnVmOworCXhmc19zYl90IAkJc2I7CisJX191aW50MzJfdAkJYnNpemU7 CisJaW50CQkJaTsKKwl4ZnNfb2ZmX3QJCW9mZjsKKworCS8qCisJICogcmVh ZCBpbiBleGlzdGluZyBmaWxlc3lzdGVtIHN1cGVyYmxvY2ssIHVzZSBpdCdz IGdlb21ldHJ5CisJICogc2V0dGluZ3MgYW5kIHplcm8gdGhlIGV4aXN0aW5n IHNlY29uZGFyeSBzdXBlcmJsb2Nrcy4KKwkgKi8KKwlidWYgPSBtZW1hbGln bihsaWJ4ZnNfZGV2aWNlX2FsaWdubWVudCgpLCBzZWN0c2l6ZSk7CisJaWYg KCFidWYpIHsKKwkJZnByaW50ZihzdGRlcnIsCisJXygiZXJyb3IgcmVhZGlu ZyBleGlzdGluZyBzdXBlcmJsb2NrIC0tIGZhaWxlZCB0byBtZW1hbGlnbiBi dWZmZXJcbiIpKTsKKwkJcmV0dXJuOworCX0KKwliemVybyhidWYsIHNlY3Rz aXplKTsKKworCWlmIChwcmVhZCh4aS0+ZGZkLCBidWYsIHNlY3RzaXplLCAw KSAhPSBzZWN0c2l6ZSkgeworCQlmcHJpbnRmKHN0ZGVyciwgXygiZXhpc3Rp bmcgc3VwZXJibG9jayByZWFkIGZhaWxlZDogJXNcbiIpLAorCQkJc3RyZXJy b3IoZXJybm8pKTsKKwkJZnJlZShidWYpOworCQlyZXR1cm47CisJfQorCWxp Ynhmc194bGF0ZV9zYihidWYsICZzYiwgMSwgWEZTX1NCX0FMTF9CSVRTKTsK KworCS8qCisJICogcGVyZm9ybSBzYW1lIGJhc2ljIHN1cGVyYmxvY2sgdmFs aWRhdGlvbiB0byBtYWtlIHN1cmUgd2UKKwkgKiBhY3R1YWxseSB6ZXJvIHNl Y29uZGFyeSBibG9ja3MKKwkgKi8KKwlpZiAoc2Iuc2JfbWFnaWNudW0gIT0g WEZTX1NCX01BR0lDIHx8IHNiLnNiX2Jsb2Nrc2l6ZSA9PSAwKQorCQlnb3Rv IGRvbmU7CisKKwlmb3IgKGJzaXplID0gMSwgaSA9IDA7IGJzaXplIDwgc2Iu c2JfYmxvY2tzaXplICYmCisJCQlpIDwgc2l6ZW9mKHNiLnNiX2Jsb2Nrc2l6 ZSkgKiBOQkJZOyBpKyspCisJCWJzaXplIDw8PSAxOworCisJaWYgKGkgPCBY RlNfTUlOX0JMT0NLU0laRV9MT0cgfHwgaSA+IFhGU19NQVhfQkxPQ0tTSVpF X0xPRyB8fAorCQkJaSAhPSBzYi5zYl9ibG9ja2xvZykKKwkJZ290byBkb25l OworCisJaWYgKHNiLnNiX2RibG9ja3MgPiAoKF9fdWludDY0X3Qpc2Iuc2Jf YWdjb3VudCAqIHNiLnNiX2FnYmxvY2tzKSB8fAorCQkJc2Iuc2JfZGJsb2Nr cyA8ICgoX191aW50NjRfdCkoc2Iuc2JfYWdjb3VudCAtIDEpICoKKwkJCQkJ IHNiLnNiX2FnYmxvY2tzICsgWEZTX01JTl9BR19CTE9DS1MpKQorCQlnb3Rv IGRvbmU7CisKKwkvKgorCSAqIGJsb2NrIHNpemUgYW5kIGJhc2ljIGdlb21l dHJ5IHNlZW1zIGFscmlnaHQsIHplcm8gdGhlIHNlY29uZGFyaWVzLgorCSAq LworCWJ6ZXJvKGJ1Ziwgc2VjdHNpemUpOworCWZvciAoaSA9IDE7IGkgPCBz Yi5zYl9hZ2NvdW50OyBpKyspICB7CisJCW9mZiA9ICh4ZnNfb2ZmX3QpaSAq IHNiLnNiX2FnYmxvY2tzIDw8IHNiLnNiX2Jsb2NrbG9nOworCQlpZiAocHdy aXRlKHhpLT5kZmQsIGJ1Ziwgc2VjdHNpemUsIG9mZikgPT0gLTEpCisJCQli cmVhazsKKwl9Citkb25lOgorCWZyZWUoYnVmKTsKK30KKwogaW50CiBtYWlu KAogCWludAkJCWFyZ2MsCkBAIC0xNDc5LDcgKzE1NDMsNyBAQCBtYWluKAog CQkJaWYgKFhGU19NSU5fUlRFWFRTSVpFIDw9IHJ0ZXh0Ynl0ZXMgJiYKIAkJ CSAgICAocnRleHRieXRlcyA8PSBYRlNfTUFYX1JURVhUU0laRSkpIHsKIAkJ CQlydGV4dGJsb2NrcyA9IHJzd2lkdGg7Ci0JCQl9IAorCQkJfQogCQl9CiAJ CWlmICghcnRleHRibG9ja3MpIHsKIAkJCXJ0ZXh0YmxvY2tzID0gKGJsb2Nr c2l6ZSA8IFhGU19NSU5fUlRFWFRTSVpFKSA/CkBAIC0xNTg3LDcgKzE2NTEs NyBAQCBtYWluKAogCWVsc2UgaWYgKCFkc2l6ZSkgewogCQlmcHJpbnRmKHN0 ZGVyciwgXygiY2FuJ3QgZ2V0IHNpemUgb2YgZGF0YSBzdWJ2b2x1bWVcbiIp KTsKIAkJdXNhZ2UoKTsKLQl9IAorCX0KIAlpZiAoZGJsb2NrcyA8IFhGU19N SU5fREFUQV9CTE9DS1MpIHsKIAkJZnByaW50ZihzdGRlcnIsCiAJXygic2l6 ZSAlbGxkIG9mIGRhdGEgc3Vidm9sdW1lIGlzIHRvbyBzbWFsbCwgbWluaW11 bSAlZCBibG9ja3NcbiIpLApAQCAtMTY2MSw3ICsxNzI1LDcgQEAgXygic2l6 ZSAlcyBzcGVjaWZpZWQgZm9yIGxvZyBzdWJ2b2x1bWUgaQogCQlsb2dibG9j a3MgPSBNQVgobG9nYmxvY2tzLAogCQkJCU1BWChYRlNfREZMX0xPR19TSVpF LAogCQkJCQltYXhfdHJfcmVzICogWEZTX0RGTF9MT0dfRkFDVE9SKSk7Ci0J CWxvZ2Jsb2NrcyA9IE1JTihsb2dibG9ja3MsIFhGU19NQVhfTE9HX0JMT0NL Uyk7IAorCQlsb2dibG9ja3MgPSBNSU4obG9nYmxvY2tzLCBYRlNfTUFYX0xP R19CTE9DS1MpOwogCQlpZiAoKGxvZ2Jsb2NrcyA8PCBibG9ja2xvZykgPiBY RlNfTUFYX0xPR19CWVRFUykgewogCQkJbG9nYmxvY2tzID0gWEZTX01BWF9M T0dfQllURVMgPj4gYmxvY2tsb2c7CiAJCX0KQEAgLTE3NDMsMjAgKzE4MDcs MjAgQEAgXygic2l6ZSAlcyBzcGVjaWZpZWQgZm9yIGxvZyBzdWJ2b2x1bWUg aQogCSAqIElmIGRzdW5pdCBpcyBhIG11bHRpcGxlIG9mIGZzIGJsb2Nrc2l6 ZSwgdGhlbiBjaGVjayB0aGF0IGlzIGEKIAkgKiBtdWx0aXBsZSBvZiB0aGUg YWdzaXplIHRvbwogCSAqLwotCWlmIChkc3VuaXQgJiYgIShCQlRPQihkc3Vu aXQpICUgYmxvY2tzaXplKSAmJiAKKwlpZiAoZHN1bml0ICYmICEoQkJUT0Io ZHN1bml0KSAlIGJsb2Nrc2l6ZSkgJiYKIAkgICAgZHN3aWR0aCAmJiAhKEJC VE9CKGRzd2lkdGgpICUgYmxvY2tzaXplKSkgewogCiAJCS8qIGNvbnZlcnQg ZnJvbSA1MTIgYnl0ZSBibG9ja3MgdG8gZnMgYmxvY2tzaXplICovCiAJCWRz dW5pdCA9IERUT0JUKGRzdW5pdCk7CiAJCWRzd2lkdGggPSBEVE9CVChkc3dp ZHRoKTsKIAotCQkvKiAKKwkJLyoKIAkJICogYWdzaXplIGlzIG5vdCBhIG11 bHRpcGxlIG9mIGRzdW5pdAogCQkgKi8KIAkJaWYgKChhZ3NpemUgJSBkc3Vu aXQpICE9IDApIHsKIAkJCS8qCi0JCQkgKiBSb3VuZCB1cCB0byBzdHJpcGUg dW5pdCBib3VuZGFyeS4gQWxzbyBtYWtlIHN1cmUgCi0JCQkgKiB0aGF0IGFn c2l6ZSBpcyBzdGlsbCBsYXJnZXIgdGhhbiAKKwkJCSAqIFJvdW5kIHVwIHRv IHN0cmlwZSB1bml0IGJvdW5kYXJ5LiBBbHNvIG1ha2Ugc3VyZQorCQkJICog dGhhdCBhZ3NpemUgaXMgc3RpbGwgbGFyZ2VyIHRoYW4KIAkJCSAqIFhGU19B R19NSU5fQkxPQ0tTKGJsb2NrbG9nKQogCQkgCSAqLwogCQkJdG1wX2Fnc2l6 ZSA9ICgoYWdzaXplICsgKGRzdW5pdCAtIDEpKS8gZHN1bml0KSAqIGRzdW5p dDsKQEAgLTE3NzAsNyArMTgzNCw3IEBAIF8oInNpemUgJXMgc3BlY2lmaWVk IGZvciBsb2cgc3Vidm9sdW1lIGkKIAkJCSAgICAodG1wX2Fnc2l6ZSA8PSBY RlNfQUdfTUFYX0JMT0NLUyhibG9ja2xvZykpICYmCiAJCQkgICAgIWRhZmxh ZykgewogCQkJCWFnc2l6ZSA9IHRtcF9hZ3NpemU7Ci0JCQkJYWdjb3VudCA9 IGRibG9ja3MvYWdzaXplICsgCisJCQkJYWdjb3VudCA9IGRibG9ja3MvYWdz aXplICsKIAkJCQkJCShkYmxvY2tzICUgYWdzaXplICE9IDApOwogCQkJCWlm IChkYXNpemUgfHwgZGFmbGFnKQogCQkJCQlmcHJpbnRmKHN0ZGVyciwKQEAg LTE3NzksNyArMTg0Myw3IEBAIF8oInNpemUgJXMgc3BlY2lmaWVkIGZvciBs b2cgc3Vidm9sdW1lIGkKIAkJCX0gZWxzZSB7CiAJCQkJaWYgKG5vZHNmbGFn KSB7CiAJCQkJCWRzdW5pdCA9IGRzd2lkdGggPSAwOwotCQkJCX0gZWxzZSB7 IAorCQkJCX0gZWxzZSB7CiAJCQkJCWZwcmludGYoc3RkZXJyLAogXygiQWxs b2NhdGlvbiBncm91cCBzaXplICglbGxkKSBpcyBub3QgYSBtdWx0aXBsZSBv ZiB0aGUgc3RyaXBlIHVuaXQgKCVkKVxuIiksCiAJCQkJCQkobG9uZyBsb25n KWFnc2l6ZSwgZHN1bml0KTsKQEAgLTE3ODksNyArMTg1Myw3IEBAIF8oIkFs bG9jYXRpb24gZ3JvdXAgc2l6ZSAoJWxsZCkgaXMgbm90IGEKIAkJfQogCQlp ZiAoZHN3aWR0aCAmJiAoKGFnc2l6ZSAlIGRzd2lkdGgpID09IDApICYmIChh Z2NvdW50ID4gMSkpIHsKIAkJCS8qIFRoaXMgaXMgYSBub24tb3B0aW1hbCBj b25maWd1cmF0aW9uIGJlY2F1c2UgYWxsIEFHcwotCQkJICogc3RhcnQgb24g dGhlIHNhbWUgZGlzayBpbiB0aGUgc3RyaXBlLiAgQ2hhbmdpbmcgCisJCQkg KiBzdGFydCBvbiB0aGUgc2FtZSBkaXNrIGluIHRoZSBzdHJpcGUuICBDaGFu Z2luZwogCQkJICogdGhlIEFHIHNpemUgYnkgb25lIHN1bml0IHdpbGwgZ3Vh cmFudGVlIHRoYXQgdGhpcwogCQkJICogZG9lcyBub3QgaGFwcGVuLgogCQkJ ICovCkBAIC0xODI2LDEyICsxODkwLDEyIEBAIGFuIEFHIHNpemUgdGhhdCBp cyBvbmUgc3RyaXBlIHVuaXQgc21hbGwKIAl9IGVsc2UgewogCQlpZiAobm9k c2ZsYWcpCiAJCQlkc3VuaXQgPSBkc3dpZHRoID0gMDsKLQkJZWxzZSB7IAor CQllbHNlIHsKIAkJCWZwcmludGYoc3RkZXJyLAogCQkJCV8oIiVzOiBTdHJp cGUgdW5pdCglZCkgb3Igc3RyaXBlIHdpZHRoKCVkKSBpcyAiCiAJCQkJIm5v dCBhIG11bHRpcGxlIG9mIHRoZSBibG9jayBzaXplKCVkKVxuIiksCi0JCQkJ cHJvZ25hbWUsIEJCVE9CKGRzdW5pdCksIEJCVE9CKGRzd2lkdGgpLCAKLQkJ CQlibG9ja3NpemUpOyAJCisJCQkJcHJvZ25hbWUsIEJCVE9CKGRzdW5pdCks IEJCVE9CKGRzd2lkdGgpLAorCQkJCWJsb2Nrc2l6ZSk7CiAJCQlleGl0KDEp OwogCQl9CiAJfQpAQCAtMjAwNSw2ICsyMDY5LDkgQEAgYW4gQUcgc2l6ZSB0 aGF0IGlzIG9uZSBzdHJpcGUgdW5pdCBzbWFsbAogCQkJKHNlY3RvcnNpemUg IT0gQkJTSVpFIHx8IGxzZWN0b3JzaXplICE9IEJCU0laRSksCiAJCQlzYnAt PnNiX2ZlYXR1cmVzMiAhPSAwKTsKIAorCWlmIChmb3JjZV9vdmVyd3JpdGUp CisJCXplcm9fb2xkX3hmc19zdHJ1Y3R1cmVzKCZ4aSwgc2VjdG9yc2l6ZSk7 CisKIAkvKgogCSAqIFplcm8gb3V0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGRl dmljZSwgdG8gb2JsaXRlcmF0ZSBhbnkgb2xkCiAJICogZmlsZXN5c3RlbSBz aWduYXR1cmVzIG91dCB0aGVyZS4gIFRoaXMgc2hvdWxkIHRha2UgY2FyZSBv ZgpAQCAtMjAzOSw3ICsyMTA2LDcgQEAgYW4gQUcgc2l6ZSB0aGF0IGlzIG9u ZSBzdHJpcGUgdW5pdCBzbWFsbAogIAkgKiAoTUQgc2IgaXMgfjY0ayBmcm9t IHRoZSBlbmQsIHRha2Ugb3V0IGEgd2lkZXIgc3dhdGggdG8gYmUgc3VyZSkK IAkgKi8KIAlpZiAoIXhpLmRpc2ZpbGUpIHsKLQkJYnVmID0gbGlieGZzX2dl dGJ1Zih4aS5kZGV2LCAoeGkuZHNpemUgLSBCVE9CQihXSEFDS19TSVpFKSks IAorCQlidWYgPSBsaWJ4ZnNfZ2V0YnVmKHhpLmRkZXYsICh4aS5kc2l6ZSAt IEJUT0JCKFdIQUNLX1NJWkUpKSwKIAkJCQkgICAgQlRPQkIoV0hBQ0tfU0la RSkpOwogCQliemVybyhYRlNfQlVGX1BUUihidWYpLCBXSEFDS19TSVpFKTsK IAkJbGlieGZzX3dyaXRlYnVmKGJ1ZiwgTElCWEZTX0VYSVRfT05fRkFJTFVS RSk7CkBAIC0yMTAxLDcgKzIxNjgsNyBAQCBhbiBBRyBzaXplIHRoYXQgaXMg b25lIHN0cmlwZSB1bml0IHNtYWxsCiAJCUlOVF9TRVQoYWdmLT5hZ2ZfbG9u Z2VzdCwgQVJDSF9DT05WRVJULCBuYm1ibG9ja3MpOwogCQlpZiAobG9naW50 ZXJuYWwgJiYgYWdubyA9PSBsb2dhZ25vKSB7CiAJCQlJTlRfTU9EKGFnZi0+ YWdmX2ZyZWVibGtzLCBBUkNIX0NPTlZFUlQsIC1sb2dibG9ja3MpOwotCQkJ SU5UX1NFVChhZ2YtPmFnZl9sb25nZXN0LCBBUkNIX0NPTlZFUlQsIGFnc2l6 ZSAtIAorCQkJSU5UX1NFVChhZ2YtPmFnZl9sb25nZXN0LCBBUkNIX0NPTlZF UlQsIGFnc2l6ZSAtCiAJCQkJWEZTX0ZTQl9UT19BR0JOTyhtcCwgbG9nc3Rh cnQpIC0gbG9nYmxvY2tzKTsKIAkJfQogCQlpZiAoWEZTX01JTl9GUkVFTElT VChhZ2YsIG1wKSA+IHdvcnN0X2ZyZWVsaXN0KQpAQCAtMjE1Myw3ICsyMjIw LDcgQEAgYW4gQUcgc2l6ZSB0aGF0IGlzIG9uZSBzdHJpcGUgdW5pdCBzbWFs bAogCQkJCSAqIEhhdmUgdG8gaW5zZXJ0IHR3byByZWNvcmRzCiAJCQkJICog SW5zZXJ0IHBhZCByZWNvcmQgZm9yIHN0cmlwZSBhbGlnbiBvZiBsb2cKIAkJ CQkgKi8KLQkJCQlJTlRfU0VUKGFyZWMtPmFyX2Jsb2NrY291bnQsIEFSQ0hf Q09OVkVSVCwgCisJCQkJSU5UX1NFVChhcmVjLT5hcl9ibG9ja2NvdW50LCBB UkNIX0NPTlZFUlQsCiAJCQkJCSh4ZnNfZXh0bGVuX3QpKFhGU19GU0JfVE9f QUdCTk8oCiAJCQkJCQltcCwgbG9nc3RhcnQpCiAJCQkJICAJLSAoSU5UX0dF VChhcmVjLT5hcl9zdGFydGJsb2NrLApAQCAtMjE2OSwxMiArMjIzNiwxMiBA QCBhbiBBRyBzaXplIHRoYXQgaXMgb25lIHN0cmlwZSB1bml0IHNtYWxsCiAJ CQkJCQlBUkNIX0NPTlZFUlQpKTsKIAkJCQlhcmVjID0gbnJlYzsKIAkJCQlJ TlRfTU9EKGJsb2NrLT5iYl9udW1yZWNzLCBBUkNIX0NPTlZFUlQsIDEpOwot CQkJfSAKKwkJCX0KIAkJCS8qCiAJCQkgKiBDaGFuZ2UgcmVjb3JkIHN0YXJ0 IHRvIGFmdGVyIHRoZSBpbnRlcm5hbCBsb2cKIAkJCSAqLwogCQkJSU5UX01P RChhcmVjLT5hcl9zdGFydGJsb2NrLCBBUkNIX0NPTlZFUlQsIGxvZ2Jsb2Nr cyk7Ci0JCX0gCisJCX0KIAkJSU5UX1NFVChhcmVjLT5hcl9ibG9ja2NvdW50 LCBBUkNIX0NPTlZFUlQsCiAJCQkoeGZzX2V4dGxlbl90KShhZ3NpemUgLQog CQkJCUlOVF9HRVQoYXJlYy0+YXJfc3RhcnRibG9jaywgQVJDSF9DT05WRVJU KSkpOwpAQCAtMjIxMiw3ICsyMjc5LDcgQEAgYW4gQUcgc2l6ZSB0aGF0IGlz IG9uZSBzdHJpcGUgdW5pdCBzbWFsbAogCQkJCUlOVF9NT0QoYmxvY2stPmJi X251bXJlY3MsIEFSQ0hfQ09OVkVSVCwgMSk7CiAJCQl9CiAJCQlJTlRfTU9E KGFyZWMtPmFyX3N0YXJ0YmxvY2ssIEFSQ0hfQ09OVkVSVCwgbG9nYmxvY2tz KTsKLQkJfQkKKwkJfQogCQlJTlRfU0VUKGFyZWMtPmFyX2Jsb2NrY291bnQs IEFSQ0hfQ09OVkVSVCwgKHhmc19leHRsZW5fdCkKIAkJCShhZ3NpemUgLSBJ TlRfR0VUKGFyZWMtPmFyX3N0YXJ0YmxvY2ssIEFSQ0hfQ09OVkVSVCkpKTsK IAkJbGlieGZzX3dyaXRlYnVmKGJ1ZiwgTElCWEZTX0VYSVRfT05fRkFJTFVS RSk7Cg== ------------1bmT4AjRtp81ALP1nN5vGp-- From owner-xfs@oss.sgi.com Wed Jul 11 02:12:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 02:12:14 -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,J_CHICKENPOX_73, J_CHICKENPOX_93 autolearn=no version=3.2.0-pre1-r499012 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6B9CAbm032394 for ; Wed, 11 Jul 2007 02:12:11 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6B88Quu017476 for ; Wed, 11 Jul 2007 04:08:26 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6B9CBhb559512 for ; Wed, 11 Jul 2007 05:12:11 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6B9CAPj000817 for ; Wed, 11 Jul 2007 05:12:10 -0400 Received: from amitarora.in.ibm.com ([9.124.31.198]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6B9C95J000781; Wed, 11 Jul 2007 05:12:10 -0400 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id 9439D29F6BB; Wed, 11 Jul 2007 14:42:26 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6B9COVZ023204; Wed, 11 Jul 2007 14:42:24 +0530 Date: Wed, 11 Jul 2007 14:42:24 +0530 From: "Amit K. Arora" To: Heikki Orsila Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH 1/7] manpage for fallocate Message-ID: <20070711091224.GA30545@amitarora.in.ibm.com> References: <20070710201200.GA10255@amitarora.in.ibm.com> <20070710201820.GA8797@amitarora.in.ibm.com> <20070710213701.GG3400@zakalwe.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070710213701.GG3400@zakalwe.fi> 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: 12123 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: 1180 Lines: 46 On Wed, Jul 11, 2007 at 12:37:01AM +0300, Heikki Orsila wrote: > On Wed, Jul 11, 2007 at 01:48:20AM +0530, Amit K. Arora wrote: > > .BI "int syscall(int, int fd, int mode, loff_t offset, loff_t len); > > Correction: "int syscall(int fd, int mode, ...)", Here, we have syscall() with first argument being the system call number - so what you suggested is not correct. But, yes, the synopsis should change at some time. Maybe to something like: #include long fallocate(int fd, int mode, loff_t offset, loff_t len); > > .TP > > .B ENOSPC > > There is not enough space left on the device containing the file > > referred to by > > .IR fd. > > .TP > > .B ESPIPE > > .I fd > > refers to a pipe of file descriptor. > > .B ENOSYS > > The filesystem underlying the file descriptor does not support this > > operation. > > EINTR? Will add following errors: EINTR A signal was caught during execution EIO An I/O error occurred while reading from or writing to a file system. EOPNOTSUPP The mode is not supported on the file descriptor. and will update following : EINVAL offset was less than 0, or len was less than or equal to 0. -- Regards, Amit Arora From owner-xfs@oss.sgi.com Wed Jul 11 02:13:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 02:13:55 -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 l6B9Dobm000787 for ; Wed, 11 Jul 2007 02:13:51 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1I8Y8K-0004r7-8d; Wed, 11 Jul 2007 10:05:16 +0100 Date: Wed, 11 Jul 2007 10:05:16 +0100 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , "Amit K. Arora" , 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: <20070711090516.GC18301@infradead.org> Mail-Followup-To: Christoph Hellwig , David Chinner , "Amit K. Arora" , 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 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.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: 12126 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: 479 Lines: 9 On Mon, Jul 02, 2007 at 08:55:43AM +1000, David Chinner wrote: > 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... Agreed, looks like we should stay with the user has to clean up behaviour. From owner-xfs@oss.sgi.com Wed Jul 11 02:13:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 02:13: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.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 l6B9Dqbm000829 for ; Wed, 11 Jul 2007 02:13:53 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1I8Y6L-0004no-1b; Wed, 11 Jul 2007 10:03:13 +0100 Date: Wed, 11 Jul 2007 10:03:12 +0100 From: Christoph Hellwig 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 Message-ID: <20070711090312.GA18301@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: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070703114650.GB14936@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: 12127 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: 1900 Lines: 39 On Tue, Jul 03, 2007 at 05:16:50PM +0530, Amit K. Arora wrote: > 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. Sorry, but this doesn't make any sense. There is no need to put every feature in the XFS ioctls in the syscalls. The XFS ioctls will need to be supported forever anyway - as I suggested before they really should be moved to generic code. What needs to be supported is what makes sense as an interface. A punch a hole interface does make sense, but trying to hack this into a preallocation system call is just madness. We're not IRIX or windows that fit things into random subcall just because there was some space left to squeeze them in. > > > > 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. HSMs needs this basically for every system call, which screams for an open flag like O_INVISIBLE anyway. Adding this in a generic way is a good idea, but hacking bits and pieces that won't fit into the global design is completely wrong. From owner-xfs@oss.sgi.com Wed Jul 11 02:13:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 02:13: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.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 l6B9Dkbm000747 for ; Wed, 11 Jul 2007 02:13:49 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1I8Y7l-0004pK-A8; Wed, 11 Jul 2007 10:04:41 +0100 Date: Wed, 11 Jul 2007 10:04:41 +0100 From: Christoph Hellwig To: Timothy Shimmin Cc: "Amit K. Arora" , 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: <20070711090441.GB18301@infradead.org> Mail-Followup-To: Christoph Hellwig , Timothy Shimmin , "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: <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> <468B31FD.2020703@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <468B31FD.2020703@sgi.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: 12125 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: 466 Lines: 12 On Wed, Jul 04, 2007 at 03:37:01PM +1000, Timothy Shimmin wrote: > 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. > You're not :) You're using an O_INVIBLE equivalent (as described below), which would be a useful thing to have at the VFS level, but adding hacks to some system calls only wouldn't help any HSM system. It's just useless API clutter. From owner-xfs@oss.sgi.com Wed Jul 11 02:13:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 02:13:49 -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 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 l6B9Dibm000703 for ; Wed, 11 Jul 2007 02:13:46 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1I8Y0f-0004kO-Ly; Wed, 11 Jul 2007 09:57:21 +0100 Date: Wed, 11 Jul 2007 09:57:21 +0100 From: Christoph Hellwig To: David Chinner Cc: xfs-dev , xfs-oss Subject: Re: Review: fix truncate vs null files issues Message-ID: <20070711085721.GB18038@infradead.org> References: <20070709073826.GO31489@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070709073826.GO31489@sgi.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: 12124 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: 991 Lines: 27 On Mon, Jul 09, 2007 at 05:38:26PM +1000, David Chinner wrote: > > When we change the file size via xfs_setattr(), we log the > new, in-memory file size in the transaction. We do this without > having flushed any dirty data so if we have previously extended > the file we change the on disk file size without having written > the data first. > > This is a problem for both growing the file and truncating the > file. The truncate case is partially hidden by the VTRUNCATE > code, but if the file has not been closed before a crash has > occurred we can still get NULLs appearing in files. > > The following patch fixes this problem by flushing the range > between the on-disk filesize and the new file size as long > as the new file size is larger than the on disk file size. > > Comments? Looks good. > + (ip->i_size != ip->i_d.di_size) && > + (vap->va_size > ip->i_d.di_size)) { And if I'd really want to get picky I'd say please remove all the superflous braces here.. From owner-xfs@oss.sgi.com Wed Jul 11 02:49:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 02:49:25 -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.0 required=5.0 tests=AWL,BAYES_99 autolearn=no version=3.2.0-pre1-r499012 Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6B9nKbm016632 for ; Wed, 11 Jul 2007 02:49:23 -0700 Received: from tyo202.gate.nec.co.jp ([10.7.69.202]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l6B8c086013875 for ; Wed, 11 Jul 2007 17:39:38 +0900 (JST) Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id l6B8Y67x019155; Wed, 11 Jul 2007 17:34:06 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id l6B8Y6Q11502; Wed, 11 Jul 2007 17:34:06 +0900 (JST) Received: from saigo.jp.nec.com (saigo.jp.nec.com [10.26.220.6]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id l6B8Y5018173; Wed, 11 Jul 2007 17:34:05 +0900 (JST) Received: from TNESG9305.wm.jp.nec.com ([10.1.104.199] [10.1.104.199]) by mail.jp.nec.com with ESMTP; Wed, 11 Jul 2007 17:34:05 +0900 Message-Id: <200707110834.AA05713@TNESG9305.wm.jp.nec.com> From: Utako Kusaka Date: Wed, 11 Jul 2007 17:34:14 +0900 To: "Barry Naujok" Cc: xfs-dev , "xfs@oss.sgi.com" Subject: Re: REVIEW: Updated all xfsprogs man pages In-Reply-To: References: MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.13 Content-Type: text/plain; charset=iso-2022-jp X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12128 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: u-kusaka@wm.jp.nec.com Precedence: bulk X-list: xfs Status: O Content-Length: 436 Lines: 14 Hi, I sent a patch more than one month ago but it is not included in your patch. Should I update my patch based on your patch and resend? http://marc.info/?l=linux-xfs&m=118050289805766&w=4 -- Utako Kusaka Tue, 10 Jul 2007 17:36:47 +1000 Barry Naujok wrote$B!'(B REVIEW: Updated all xfsprogs man pages >- Updated out of date information. >- Updated formatting to linux standards. >- Improved readability of some complex sections. From owner-xfs@oss.sgi.com Wed Jul 11 11:10:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 11:10: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=3.1 required=5.0 tests=AWL,BAYES_80,J_CHICKENPOX_43, SPF_HELO_PASS 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 l6BIA9bm029547 for ; Wed, 11 Jul 2007 11:10:11 -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 l6BIAATb011463; Wed, 11 Jul 2007 14:10:10 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6BIA9tQ002315; Wed, 11 Jul 2007 14:10:09 -0400 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id l6BIA6Kp028822; Wed, 11 Jul 2007 14:10:08 -0400 Message-ID: <46951C0A.4080505@sandeen.net> Date: Wed, 11 Jul 2007 13:06:02 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Barry Naujok CC: "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: zero existing secondary superblocks with mkfs.xfs -f References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 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: 12129 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: 867 Lines: 30 Barry Naujok wrote: > The attached patch zeros all the secondary superblocks if > overwriting an existing XFS filesystem. > > This allows xfs_repair to detect the correct secondary block > if the primary is destroyed (like XFS QA test 030). Seems good to me (after filtering out all of the quilt-induced whitespace changes ;-) ) + /* + * perform same basic superblock validation to make sure we + * actually zero secondary blocks + */ + if (sb.sb_magicnum != XFS_SB_MAGIC || sb.sb_blocksize == 0) + goto done; Is there any chance we'd be here if the first test weren't already true? *shrug* harmless though I guess. If something goes wrong and the old found SB is full of junk, this is non-fatal, right. Out of curiosity, why not just call verify_sb for the sanity checks instead of recreating a subset of them in zero_old_xfs_structures? Thanks, -Eric From owner-xfs@oss.sgi.com Wed Jul 11 16:35:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 16:35:47 -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 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 l6BNZgbm006065 for ; Wed, 11 Jul 2007 16:35:44 -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 JAA00494; Thu, 12 Jul 2007 09:35:36 +1000 Message-ID: <469569CC.1010904@sgi.com> Date: Thu, 12 Jul 2007 09:37:48 +1000 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.12 (X11/20070509) MIME-Version: 1.0 To: John Groves CC: linux-xfs@oss.sgi.com Subject: Re: XFS capacity leak with dmapi References: In-Reply-To: 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: 12130 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: 1320 Lines: 36 John Groves wrote: > Vlad, I've tried to send this via linux-xfs, but for some reason my > posts aren't going through (although I receive messages from it every > day). Any ideas on this? > > We have an application that uses DMAPI, and we've been chasing an XFS > filesystem capacity leak for a week or two. Here is the scenario: > > In some cases we initially create sparse files - normal open with > O_CREAT and than an ftruncate to the desired size. > > If we subsequently fill the files via dm_write_invis(), and then > remove/unlink the files, XFS does not appear to free up the capacity > that was allocated when the file was made non-sparse via > dm_write_invis(). Repeating this sequence enough times results in a > full filesystem. > > If we use write() to fill the file (after creating it as sparse), > remove/unlink appears to work properly, and capacity does not appear > to be leaked. We've seen this on several test systems; the current > one is 2.6.22-rc4, which I think is current as to the SGI cvs tree (or > very nearly so). > > Can anybody shed light on this? > > Thanks, > John Groves Hi John, I will investigate this problem but at the moment I can't immediately jump on it. I am copying the email to linux-xfs list in case if someone could answer it straightaway. Regards, Vlad From owner-xfs@oss.sgi.com Wed Jul 11 17:15:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 17:15:28 -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,J_CHICKENPOX_43 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 l6C0FMbm021904 for ; Wed, 11 Jul 2007 17:15:24 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02720; Thu, 12 Jul 2007 10:15:19 +1000 Date: Thu, 12 Jul 2007 10:19:11 +1000 To: "Eric Sandeen" Subject: Re: REVIEW: zero existing secondary superblocks with mkfs.xfs -f From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" , xfs-dev Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <46951C0A.4080505@sandeen.net> Message-ID: In-Reply-To: <46951C0A.4080505@sandeen.net> User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id l6C0FPbm021970 X-archive-position: 12131 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 1395 Lines: 43 On Thu, 12 Jul 2007 04:06:02 +1000, Eric Sandeen wrote: > Barry Naujok wrote: >> The attached patch zeros all the secondary superblocks if >> overwriting an existing XFS filesystem. >> >> This allows xfs_repair to detect the correct secondary block >> if the primary is destroyed (like XFS QA test 030). > > Seems good to me (after filtering out all of the quilt-induced > whitespace changes ;-) ) Doh, forgot to prune that. > + /* > + * perform same basic superblock validation to make sure we > + * actually zero secondary blocks > + */ > + if (sb.sb_magicnum != XFS_SB_MAGIC || sb.sb_blocksize == 0) > + goto done; > > Is there any chance we'd be here if the first test weren't already true? > *shrug* harmless though I guess. It's quite easy to get there if you run mkfs.xfs -f on non-XFS filesystem. > If something goes wrong and the old found SB is full of junk, this is > non-fatal, right. Yep. Worst that will happen is the pwrite loop fails, and if so, it stops and exits. Maybe one subtle enhancement is to make sure the pwrite loop doesn't extend beyond the new filesystem size. > Out of curiosity, why not just call verify_sb for the sanity checks > instead of recreating a subset of them in zero_old_xfs_structures? Because that code is in xfs_repair and not mkfs. With mkfs.xfs, we don't really care if anything else in the SB is bad. Barry. From owner-xfs@oss.sgi.com Wed Jul 11 19:31:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 19:31: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.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 l6C2V7bm020708 for ; Wed, 11 Jul 2007 19:31:09 -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 MAA08160; Thu, 12 Jul 2007 12:31:06 +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 l6C2V3eW20746684; Thu, 12 Jul 2007 12:31:04 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6C2V0w520775310; Thu, 12 Jul 2007 12:31:00 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 12 Jul 2007 12:31:00 +1000 From: David Chinner To: Nick Piggin Cc: Andrew Morton , linux-kernel@vger.kernel.org, Linux Memory Management , linux-fsdevel , xfs-oss Subject: block_page_mkwrite? (Re: fault vs invalidate race (Re: -mm merge plans for 2.6.23)) Message-ID: <20070712023100.GX12413810@sgi.com> References: <20070710013152.ef2cd200.akpm@linux-foundation.org> <46957BE1.1010104@yahoo.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46957BE1.1010104@yahoo.com.au> 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: 12132 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: 917 Lines: 31 On Thu, Jul 12, 2007 at 10:54:57AM +1000, Nick Piggin wrote: > Andrew Morton wrote: > > The fault-vs-invalidate race fix. I have belatedly learned that these > > need > > more work, so their state is uncertain. > > The more work may turn out being too much for you (although it is nothing > exactly tricky that would introduce subtle bugs, it is a fair amont of > churn). OK, so does that mean we can finally get the block_page_mkwrite patches merged? i.e.: http://marc.info/?l=linux-kernel&m=117426058311032&w=2 http://marc.info/?l=linux-kernel&m=117426070111136&w=2 I've got up-to-date versions of them ready to go and they've been consistently tested thanks to the XFSQA test I wrote for the bug that it fixes. I've been holding them out-of-tree for months now because ->fault was supposed to supercede this interface..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Jul 11 19:35:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 19:35:49 -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.9 required=5.0 tests=AWL,BAYES_99,J_CHICKENPOX_43, SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6C2Zkbm022841 for ; Wed, 11 Jul 2007 19:35:47 -0700 Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id F3E281807F9B8; Wed, 11 Jul 2007 21:35:46 -0500 (CDT) Message-ID: <46959382.5060309@sandeen.net> Date: Wed, 11 Jul 2007 21:35:46 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Barry Naujok CC: "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: zero existing secondary superblocks with mkfs.xfs -f References: <46951C0A.4080505@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 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: 12133 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: 1054 Lines: 35 Barry Naujok wrote: > On Thu, 12 Jul 2007 04:06:02 +1000, Eric Sandeen > wrote: >> + if (sb.sb_magicnum != XFS_SB_MAGIC || sb.sb_blocksize == 0) >> + goto done; >> >> Is there any chance we'd be here if the first test weren't already true? >> *shrug* harmless though I guess. > > It's quite easy to get there if you run mkfs.xfs -f on non-XFS > filesystem. Oh, duh. Of course. >> If something goes wrong and the old found SB is full of junk, this is >> non-fatal, right. > > Yep. Worst that will happen is the pwrite loop fails, and if so, it > stops and exits. Maybe one subtle enhancement is to make sure the > pwrite loop doesn't extend beyond the new filesystem size. > >> Out of curiosity, why not just call verify_sb for the sanity checks >> instead of recreating a subset of them in zero_old_xfs_structures? > > Because that code is in xfs_repair and not mkfs. With mkfs.xfs, we > don't really care if anything else in the SB is bad. Maybe a libxfs candidate? But, ok. Just a thought. :) -Eric > Barry. > From owner-xfs@oss.sgi.com Wed Jul 11 21:27:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 21:27: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=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 l6C4RKbm002575 for ; Wed, 11 Jul 2007 21:27:24 -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 OAA10900; Thu, 12 Jul 2007 14:27:17 +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 l6C4RFeW20804061; Thu, 12 Jul 2007 14:27:16 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6C4RD5g19932467; Thu, 12 Jul 2007 14:27:13 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 12 Jul 2007 14:27:13 +1000 From: David Chinner To: lkml Cc: xfs-oss Subject: [PATCH, RESEND] Export radix_tree_preload() Message-ID: <20070712042713.GP31489@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: 12134 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: 896 Lines: 27 Upcoming XFS functionality [1] we plan to merge in 2.6.23-rc1 uses radix trees and uses the preload functions. XFS can be built as a module and hence we need radix_tree_preload() exported. radix_tree_preload_end() is a static inline, so it doesn't need exporting. [1] http://oss.sgi.com/archives/xfs/2007-07/msg00029.html Signed-Off-By: Dave Chinner --- lib/radix-tree.c | 1 + 1 file changed, 1 insertion(+) Index: 2.6.x-xfs-new/lib/radix-tree.c =================================================================== --- 2.6.x-xfs-new.orig/lib/radix-tree.c 2007-03-29 19:00:53.802804161 +1000 +++ 2.6.x-xfs-new/lib/radix-tree.c 2007-03-29 19:07:10.297495640 +1000 @@ -151,6 +151,7 @@ int radix_tree_preload(gfp_t gfp_mask) out: return ret; } +EXPORT_SYMBOL(radix_tree_preload); static inline void tag_set(struct radix_tree_node *node, unsigned int tag, int offset) From owner-xfs@oss.sgi.com Wed Jul 11 21:45:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 21:45:51 -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 l6C4jhbm010835 for ; Wed, 11 Jul 2007 21:45:46 -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 OAA11382; Thu, 12 Jul 2007 14:45:40 +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 l6C4jbeW20818451; Thu, 12 Jul 2007 14:45:39 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6C4jZp920808508; Thu, 12 Jul 2007 14:45:35 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 12 Jul 2007 14:45:35 +1000 From: David Chinner To: lkml Cc: linux-fsdevel , xfs-oss Subject: [PATCH 1 of 2] block_page_mkwrite V2 Message-ID: <20070712044535.GQ31489@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: 12135 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: 3868 Lines: 99 Generic page_mkwrite functionality. Filesystems that make use of the VM ->page_mkwrite() callout will generally use the same core code to implement it. There are several tricky truncate-related issues that we need to deal with here as we cannot take the i_mutex as we normally would for these paths. These issues are not documented anywhere yet so block_page_mkwrite() seems like the best place to start. Version 2: - read inode size only once - more comments explaining implementation restrictions Signed-Off-By: Dave Chinner --- fs/buffer.c | 47 ++++++++++++++++++++++++++++++++++++++++++++ include/linux/buffer_head.h | 2 + 2 files changed, 49 insertions(+) Index: 2.6.x-xfs-new/fs/buffer.c =================================================================== --- 2.6.x-xfs-new.orig/fs/buffer.c 2007-03-17 10:55:32.291414968 +1100 +++ 2.6.x-xfs-new/fs/buffer.c 2007-03-19 08:13:54.519909087 +1100 @@ -2194,6 +2194,52 @@ int generic_commit_write(struct file *fi return 0; } +/* + * block_page_mkwrite() is not allowed to change the file size as it gets + * called from a page fault handler when a page is first dirtied. Hence we must + * be careful to check for EOF conditions here. We set the page up correctly + * for a written page which means we get ENOSPC checking when writing into + * holes and correct delalloc and unwritten extent mapping on filesystems that + * support these features. + * + * We are not allowed to take the i_mutex here so we have to play games to + * protect against truncate races as the page could now be beyond EOF. Because + * vmtruncate() writes the inode size before removing pages, once we have the + * page lock we can determine safely if the page is beyond EOF. If it is not + * beyond EOF, then the page is guaranteed safe against truncation until we + * unlock the page. + */ +int +block_page_mkwrite(struct vm_area_struct *vma, struct page *page, + get_block_t get_block) +{ + struct inode *inode = vma->vm_file->f_path.dentry->d_inode; + unsigned long end; + loff_t size; + int ret = -EINVAL; + + lock_page(page); + size = i_size_read(inode); + if ((page->mapping != inode->i_mapping) || + ((page->index << PAGE_CACHE_SHIFT) > size)) { + /* page got truncated out from underneath us */ + goto out_unlock; + } + + /* page is wholly or partially inside EOF */ + if (((page->index + 1) << PAGE_CACHE_SHIFT) > size) + end = size & ~PAGE_CACHE_MASK; + else + end = PAGE_CACHE_SIZE; + + ret = block_prepare_write(page, 0, end, get_block); + if (!ret) + ret = block_commit_write(page, 0, end); + +out_unlock: + unlock_page(page); + return ret; +} /* * nobh_prepare_write()'s prereads are special: the buffer_heads are freed @@ -2997,6 +3043,7 @@ EXPORT_SYMBOL(__brelse); EXPORT_SYMBOL(__wait_on_buffer); EXPORT_SYMBOL(block_commit_write); EXPORT_SYMBOL(block_prepare_write); +EXPORT_SYMBOL(block_page_mkwrite); EXPORT_SYMBOL(block_read_full_page); EXPORT_SYMBOL(block_sync_page); EXPORT_SYMBOL(block_truncate_page); Index: 2.6.x-xfs-new/include/linux/buffer_head.h =================================================================== --- 2.6.x-xfs-new.orig/include/linux/buffer_head.h 2007-03-17 10:55:32.135435539 +1100 +++ 2.6.x-xfs-new/include/linux/buffer_head.h 2007-03-17 10:55:32.567378573 +1100 @@ -206,6 +206,8 @@ int cont_prepare_write(struct page*, uns int generic_cont_expand(struct inode *inode, loff_t size); int generic_cont_expand_simple(struct inode *inode, loff_t size); int block_commit_write(struct page *page, unsigned from, unsigned to); +int block_page_mkwrite(struct vm_area_struct *vma, struct page *page, + get_block_t get_block); void block_sync_page(struct page *); sector_t generic_block_bmap(struct address_space *, sector_t, get_block_t *); int generic_commit_write(struct file *, struct page *, unsigned, unsigned); From owner-xfs@oss.sgi.com Wed Jul 11 21:47:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 21:47:49 -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 l6C4lhbm012063 for ; Wed, 11 Jul 2007 21:47:45 -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 OAA11477; Thu, 12 Jul 2007 14:47:39 +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 l6C4lceW20819800; Thu, 12 Jul 2007 14:47:38 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6C4laNB20815060; Thu, 12 Jul 2007 14:47:36 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 12 Jul 2007 14:47:36 +1000 From: David Chinner To: lkml Cc: linux-fsdevel , xfs-oss Subject: [PATCH 2 of 2] Make XFS use block_page_mkwrite Message-ID: <20070712044736.GR31489@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: 12136 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: 1527 Lines: 49 Implement ->page_mkwrite in XFS. Signed-Off-By: Dave Chinner --- fs/xfs/linux-2.6/xfs_file.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-02-07 23:00:10.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-02-07 23:15:20.170880823 +1100 @@ -446,6 +446,20 @@ xfs_file_open_exec( } #endif /* HAVE_FOP_OPEN_EXEC */ +/* + * mmap()d file has taken write protection fault and is being made + * writable. We can set the page state up correctly for a writable + * page, which means we can do correct delalloc accounting (ENOSPC + * checking!) and unwritten extent mapping. + */ +STATIC int +xfs_vm_page_mkwrite( + struct vm_area_struct *vma, + struct page *page) +{ + return block_page_mkwrite(vma, page, xfs_get_blocks); +} + const struct file_operations xfs_file_operations = { .llseek = generic_file_llseek, .read = do_sync_read, @@ -503,12 +517,14 @@ const struct file_operations xfs_dir_fil static struct vm_operations_struct xfs_file_vm_ops = { .nopage = filemap_nopage, .populate = filemap_populate, + .page_mkwrite = xfs_vm_page_mkwrite, }; #ifdef HAVE_DMAPI static struct vm_operations_struct xfs_dmapi_file_vm_ops = { .nopage = xfs_vm_nopage, .populate = filemap_populate, + .page_mkwrite = xfs_vm_page_mkwrite, #ifdef HAVE_VMOP_MPROTECT .mprotect = xfs_vm_mprotect, #endif From owner-xfs@oss.sgi.com Wed Jul 11 22:40:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 11 Jul 2007 22:40:14 -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 l6C5e7bm000334 for ; Wed, 11 Jul 2007 22:40:10 -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 PAA13293; Thu, 12 Jul 2007 15:40:00 +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 l6C5dweW20820084; Thu, 12 Jul 2007 15:39:59 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6C5duB220830139; Thu, 12 Jul 2007 15:39:56 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 12 Jul 2007 15:39:56 +1000 From: David Chinner To: lkml Cc: linux-fsdevel , xfs-oss Subject: [PATCH, RESEND] Teach do_mpage_readpage() about unwritten buffers Message-ID: <20070712053956.GT31489@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: 12137 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 Thu Jul 12 01:26:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 01:26: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.9 required=5.0 tests=AWL,BAYES_60 autolearn=no version=3.2.0-pre1-r499012 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6C8Qjbm008493 for ; Thu, 12 Jul 2007 01:26:48 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6C8QlWO012806 for ; Thu, 12 Jul 2007 04:26:47 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6C8QmfL421530 for ; Thu, 12 Jul 2007 04:26:48 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6C8QlMw025171 for ; Thu, 12 Jul 2007 04:26:47 -0400 Received: from amitarora.in.ibm.com (amitarora.in.ibm.com [9.124.31.198]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6C8Qkj0025157; Thu, 12 Jul 2007 04:26:46 -0400 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id A144D93BD2; Thu, 12 Jul 2007 13:56:52 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6C8QoqM003183; Thu, 12 Jul 2007 13:56:50 +0530 Date: Thu, 12 Jul 2007 13:56:50 +0530 From: "Amit K. Arora" To: Suparna Bhattacharya Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, adilger@clusterfs.com, David Chinner , cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070712082650.GB12817@amitarora.in.ibm.com> References: <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> <20070711090312.GA18301@infradead.org> <20070712072813.GA31260@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712072813.GA31260@in.ibm.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: 12138 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: 3134 Lines: 73 On Thu, Jul 12, 2007 at 12:58:13PM +0530, Suparna Bhattacharya wrote: > On Wed, Jul 11, 2007 at 10:03:12AM +0100, Christoph Hellwig wrote: > > On Tue, Jul 03, 2007 at 05:16:50PM +0530, Amit K. Arora wrote: > > > 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. > > > > Sorry, but this doesn't make any sense. There is no need to put every > > feature in the XFS ioctls in the syscalls. The XFS ioctls will need to > > be supported forever anyway - as I suggested before they really should > > be moved to generic code. > > > > What needs to be supported is what makes sense as an interface. > > A punch a hole interface does make sense, but trying to hack this into > > a preallocation system call is just madness. We're not IRIX or windows > > that fit things into random subcall just because there was some space > > left to squeeze them in. > > > > > > > > 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. > > > > HSMs needs this basically for every system call, which screams for an > > open flag like O_INVISIBLE anyway. Adding this in a generic way is > > a good idea, but hacking bits and pieces that won't fit into the global > > design is completely wrong. > > Why don't we just merge the interface for preallocation (essentially > enough to satisfy posix_fallocate() and the simple XFS requirement for > space reservation without changing file size), which there is clear agreement > on (I hope :)). After all, this was all that we set out to do when we > started. As you suggest, let us just have two modes for the time being: #define FALLOC_ALLOCATE 0x1 #define FALLOC_ALLOCATE_KEEP_SIZE 0x2 As the name suggests, when FALLOC_ALLOCATE_KEEP_SIZE mode is passed it will result in file size not being changed even if the preallocation is beyond EOF. > And leave all the dealloc/punch/hsm type features for separate future patches/ > debates, those really shouldn't hold up the basic fallocate interface. I agree. > I agree with Christoph that we are just diverging too much in trying to > club those decisions here. > > Dave, Andreas, Ted ? > > Regards > Suparna -- Regards, Amit Arora From owner-xfs@oss.sgi.com Thu Jul 12 06:33:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 06:33:20 -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 l6CDWvbm032060 for ; Thu, 12 Jul 2007 06:33:00 -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 XAA24038; Thu, 12 Jul 2007 23:13:46 +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 l6CDDfeW21063260; Thu, 12 Jul 2007 23:13:42 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6CDDY3l21086897; Thu, 12 Jul 2007 23:13:34 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 12 Jul 2007 23:13:34 +1000 From: David Chinner To: Suparna Bhattacharya Cc: 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 , cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070712131334.GY31489@sgi.com> References: <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> <20070711090312.GA18301@infradead.org> <20070712072813.GA31260@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712072813.GA31260@in.ibm.com> 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: 12139 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: 820 Lines: 25 On Thu, Jul 12, 2007 at 12:58:13PM +0530, Suparna Bhattacharya wrote: > > Why don't we just merge the interface for preallocation (essentially > enough to satisfy posix_fallocate() and the simple XFS requirement for > space reservation without changing file size), which there is clear agreement > on (I hope :)). After all, this was all that we set out to do when we > started. > > And leave all the dealloc/punch/hsm type features for separate future patches/ > debates, those really shouldn't hold up the basic fallocate interface. > I agree with Christoph that we are just diverging too much in trying to > club those decisions here. > > Dave, Andreas, Ted ? Sure. I'll just make XFS work with whatever it is that gets merged. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jul 12 07:15:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 07:15:26 -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.4 required=5.0 tests=AWL,BAYES_50 autolearn=no version=3.2.0-pre1-r499012 Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6CEF7bm022516 for ; Thu, 12 Jul 2007 07:15:11 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6CEF6Sv019246 for ; Thu, 12 Jul 2007 10:15:06 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6CEF1xh149892 for ; Thu, 12 Jul 2007 08:15:03 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6CEF1wo002566 for ; Thu, 12 Jul 2007 08:15:01 -0600 Received: from amitarora.in.ibm.com (amitarora.in.ibm.com [9.124.31.198]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6CEF0V8002388; Thu, 12 Jul 2007 08:15:00 -0600 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id EE07493BD2; Thu, 12 Jul 2007 19:45:17 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6CEFGwr000378; Thu, 12 Jul 2007 19:45:16 +0530 Date: Thu, 12 Jul 2007 19:45:16 +0530 From: "Amit K. Arora" To: David Chinner Cc: Suparna Bhattacharya , Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, adilger@clusterfs.com, cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070712141516.GC21606@amitarora.in.ibm.com> References: <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> <20070711090312.GA18301@infradead.org> <20070712072813.GA31260@in.ibm.com> <20070712131334.GY31489@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712131334.GY31489@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: 12140 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: 899 Lines: 24 On Thu, Jul 12, 2007 at 11:13:34PM +1000, David Chinner wrote: > On Thu, Jul 12, 2007 at 12:58:13PM +0530, Suparna Bhattacharya wrote: > > > > Why don't we just merge the interface for preallocation (essentially > > enough to satisfy posix_fallocate() and the simple XFS requirement for > > space reservation without changing file size), which there is clear agreement > > on (I hope :)). After all, this was all that we set out to do when we > > started. > > > > And leave all the dealloc/punch/hsm type features for separate future patches/ > > debates, those really shouldn't hold up the basic fallocate interface. > > I agree with Christoph that we are just diverging too much in trying to > > club those decisions here. > > > > Dave, Andreas, Ted ? > > Sure. I'll just make XFS work with whatever it is that gets merged. Great. I will post the new patches soon. -- Regards, Amit Arora From owner-xfs@oss.sgi.com Thu Jul 12 07:41:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 07:41:17 -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.5 required=5.0 tests=BAYES_50,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 l6CEeubm032429 for ; Thu, 12 Jul 2007 07:40:59 -0700 Received: from localhost.adilger.int (unknown [12.10.172.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.clusterfs.com (Postfix) with ESMTP id 941B57BA377; Thu, 12 Jul 2007 08:40:57 -0600 (MDT) Received: by localhost.adilger.int (Postfix, from userid 1000) id 27A953FB2; Thu, 12 Jul 2007 08:40:55 -0600 (MDT) Date: Thu, 12 Jul 2007 08:40:55 -0600 From: Andreas Dilger To: "Amit K. Arora" Cc: Suparna Bhattacharya , Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, David Chinner , cmm@us.ibm.com, xfs@oss.sgi.com Subject: Re: [PATCH 4/7][TAKE5] support new modes in fallocate Message-ID: <20070712144055.GH5586@schatzie.adilger.int> Mail-Followup-To: "Amit K. Arora" , Suparna Bhattacharya , Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, David Chinner , cmm@us.ibm.com, xfs@oss.sgi.com References: <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> <20070711090312.GA18301@infradead.org> <20070712072813.GA31260@in.ibm.com> <20070712082650.GB12817@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712082650.GB12817@amitarora.in.ibm.com> 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: 12141 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: 701 Lines: 21 On Jul 12, 2007 13:56 +0530, Amit K. Arora wrote: > As you suggest, let us just have two modes for the time being: > > #define FALLOC_ALLOCATE 0x1 > #define FALLOC_ALLOCATE_KEEP_SIZE 0x2 > > As the name suggests, when FALLOC_ALLOCATE_KEEP_SIZE mode is passed it > will result in file size not being changed even if the preallocation is > beyond EOF. What does FALLOC_ALLOCATE mean vs. not passing this flag? I have no objection to this as long as the code remains with these as "flags" instead of "modes"... Essentially just dropping the FALLOC_FL_DEALLOCATE and FALLOC_FL_DEL_DATA from the interface. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. From owner-xfs@oss.sgi.com Thu Jul 12 08:28:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 08:28: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.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 l6CFSibm025540 for ; Thu, 12 Jul 2007 08:28:46 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1I90DX-00013I-Pz for xfs@oss.sgi.com; Thu, 12 Jul 2007 16:04:31 +0100 Date: Thu, 12 Jul 2007 16:04:31 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com Subject: xfsqa 144 is failing now Message-ID: <20070712150431.GA3763@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 12142 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: 1131 Lines: 27 I'm trying to fix up dmapi for the patch that uses filldir internally, and 144 is the xfsqa test for this functionality. It worked fine a few weeks ago when I started that work but fails with plain TOT linux-xfs now with errors like: < report: get #0 had no errors. < report: get #1 had no errors. --- > ERROR: get #0, expected mode 35034, but found 33188 > ERROR: get #0, expected uid -756063452, but found 0 > ERROR: get #0, expected gid 323693819, but found 0 > ERROR: get #0, expected mtime -424339458, but found 1184248449 > ERROR: get #0, expected ctime -862739105, but found 1184248449 > ERROR: get #0, expected dtime -862739105, but found 1184248449 > ERROR: get #0, expected size 1125898004553757, but found 29696 > report: 1 tests correct for get #0. > ERROR: get #1, expected mode 34544, but found 33188 > ERROR: get #1, expected uid -1407127963, but found 0 > ERROR: get #1, expected gid 1043573623, but found 0 > ERROR: get #1, expected mtime -1589334486, but found does anyone have an idea what might be causing this? The only recent changes to xfs_dm.c are the hole punching fixes which seem rather unrelated. From owner-xfs@oss.sgi.com Thu Jul 12 09:43:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 09:45:10 -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.9 required=5.0 tests=AWL,BAYES_80,SPF_HELO_PASS autolearn=no version=3.2.0-pre1-r499012 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6CGhrbm029577 for ; Thu, 12 Jul 2007 09:43:55 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 1B5E61C099302; Thu, 12 Jul 2007 12:43:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 196E94019500; Thu, 12 Jul 2007 12:43:56 -0400 (EDT) Date: Thu, 12 Jul 2007 12:43:56 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Christoph Hellwig cc: xfs@oss.sgi.com Subject: Re: xfsqa 144 is failing now In-Reply-To: <20070712150431.GA3763@infradead.org> Message-ID: References: <20070712150431.GA3763@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12143 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Status: O Content-Length: 1267 Lines: 35 On Thu, 12 Jul 2007, Christoph Hellwig wrote: > I'm trying to fix up dmapi for the patch that uses filldir internally, > and 144 is the xfsqa test for this functionality. It worked fine a > few weeks ago when I started that work but fails with plain TOT linux-xfs > now with errors like: > > > < report: get #0 had no errors. > < report: get #1 had no errors. > --- >> ERROR: get #0, expected mode 35034, but found 33188 >> ERROR: get #0, expected uid -756063452, but found 0 >> ERROR: get #0, expected gid 323693819, but found 0 >> ERROR: get #0, expected mtime -424339458, but found 1184248449 >> ERROR: get #0, expected ctime -862739105, but found 1184248449 >> ERROR: get #0, expected dtime -862739105, but found 1184248449 >> ERROR: get #0, expected size 1125898004553757, but found 29696 >> report: 1 tests correct for get #0. >> ERROR: get #1, expected mode 34544, but found 33188 >> ERROR: get #1, expected uid -1407127963, but found 0 >> ERROR: get #1, expected gid 1043573623, but found 0 >> ERROR: get #1, expected mtime -1589334486, but found > > does anyone have an idea what might be causing this? > > The only recent changes to xfs_dm.c are the hole punching fixes which > seem rather unrelated. > > Curious, what do you use that utilizes DMAPI? From owner-xfs@oss.sgi.com Thu Jul 12 09:52:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 09:52:20 -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 l6CGqEbm032555 for ; Thu, 12 Jul 2007 09:52:16 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1I91to-0002BJ-HD; Thu, 12 Jul 2007 17:52:16 +0100 Date: Thu, 12 Jul 2007 17:52:16 +0100 From: Christoph Hellwig To: Justin Piszcz Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: xfsqa 144 is failing now Message-ID: <20070712165216.GA8357@infradead.org> References: <20070712150431.GA3763@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: 12144 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: 192 Lines: 6 On Thu, Jul 12, 2007 at 12:43:56PM -0400, Justin Piszcz wrote: > Curious, what do you use that utilizes DMAPI? xfsqa :) There's a lot of dmapi tests in there, including the one that fails. From owner-xfs@oss.sgi.com Thu Jul 12 15:23:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 15:23:29 -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 l6CMNBbm013055 for ; Thu, 12 Jul 2007 15:23:17 -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 IAA10282; Fri, 13 Jul 2007 08:23:07 +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 l6CMN6eW21799979; Fri, 13 Jul 2007 08:23:07 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6CMN5I521803658; Fri, 13 Jul 2007 08:23:05 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 13 Jul 2007 08:23:05 +1000 From: David Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: xfsqa 144 is failing now Message-ID: <20070712222304.GA31489@sgi.com> References: <20070712150431.GA3763@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712150431.GA3763@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: 12145 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: 1694 Lines: 46 On Thu, Jul 12, 2007 at 04:04:31PM +0100, Christoph Hellwig wrote: > I'm trying to fix up dmapi for the patch that uses filldir internally, > and 144 is the xfsqa test for this functionality. It worked fine a > few weeks ago when I started that work but fails with plain TOT linux-xfs > now with errors like: > > > < report: get #0 had no errors. > < report: get #1 had no errors. > --- > > ERROR: get #0, expected mode 35034, but found 33188 > > ERROR: get #0, expected uid -756063452, but found 0 > > ERROR: get #0, expected gid 323693819, but found 0 > > ERROR: get #0, expected mtime -424339458, but found 1184248449 > > ERROR: get #0, expected ctime -862739105, but found 1184248449 > > ERROR: get #0, expected dtime -862739105, but found 1184248449 > > ERROR: get #0, expected size 1125898004553757, but found 29696 > > report: 1 tests correct for get #0. > > ERROR: get #1, expected mode 34544, but found 33188 > > ERROR: get #1, expected uid -1407127963, but found 0 > > ERROR: get #1, expected gid 1043573623, but found 0 > > ERROR: get #1, expected mtime -1589334486, but found > > does anyone have an idea what might be causing this? Not yet - AFAIK we're only seeing it on i386 ATM, and we only noticed it in the past couple of days. Nobody has had a chance to look at it yet. I don't think dmapi has been tested regularly on i386 so I'm not sure when the problem first appeared yet. > The only recent changes to xfs_dm.c are the hole punching fixes which > seem rather unrelated. *nod* Given the expected output, I wouldn't be surprised if we've got some kind of 32/64 bit problem here.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Jul 12 17:38:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 17:38: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.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 l6D0cibm010322 for ; Thu, 12 Jul 2007 17:38:47 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14495; Fri, 13 Jul 2007 10:38:45 +1000 Date: Fri, 13 Jul 2007 10:41:47 +1000 To: "xfs@oss.sgi.com" , xfs-dev Subject: REVIEW: Make sure xfs_repair uses sector aligned I/O From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------uxUULPiKOb4497tspFf8oZ MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.10 (Win32) X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12146 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Status: O Content-Length: 9875 Lines: 173 ------------uxUULPiKOb4497tspFf8oZ Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Two places it didn't: - reading the initial primary superblock - checking the log The log checking fix was basically porting the kernel xlog_bread/xlog_get_bp/xlog_align from the kernel and setting up the log_t structure properly in Phase 2. The initial primary superblock read is now done using the maximum supported sector size as once the block is read and translated to another location, it's discarded. ------------uxUULPiKOb4497tspFf8oZ Content-Disposition: attachment; filename=sector_aligned_repair.patch Content-Type: application/octet-stream; name=sector_aligned_repair.patch Content-Transfer-Encoding: Base64 Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNwcm9ncy9pbmNs dWRlL2xpYnhmcy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoK LS0tIGEveGZzcHJvZ3MvaW5jbHVkZS9saWJ4ZnMuaAkyMDA3LTA3LTEzIDEw OjM1OjM4LjAwMDAwMDAwMCArMTAwMAorKysgYi94ZnNwcm9ncy9pbmNsdWRl L2xpYnhmcy5oCTIwMDctMDctMTIgMTg6NDQ6MTQuNDc0Njc0OTg3ICsxMDAw CkBAIC0yMzYsOSArMjM2LDkgQEAgZW51bSB4ZnNfYnVmX2ZsYWdzX3Qgewkv KiBiX2ZsYWdzIGJpdHMgKgogI2RlZmluZSBYRlNfQlVGX0NPVU5UKGJwKQkJ KChicCktPmJfYmNvdW50KQogI2RlZmluZSBYRlNfQlVGX1RBUkdFVChicCkJ CSgoYnApLT5iX2RldikKICNkZWZpbmUgWEZTX0JVRl9TRVRfUFRSKGJwLHAs Y250KQkoKGJwKS0+Yl9hZGRyID0gKGNoYXIgKikocCkpOyBcCi0JCQkJCQlY RlNfQlVGX1NFVENPVU5UKGJwLGNudCkKKwkJCQkJCVhGU19CVUZfU0VUX0NP VU5UKGJwLGNudCkKICNkZWZpbmUgWEZTX0JVRl9TRVRfQUREUihicCxibGsp CSgoYnApLT5iX2Jsa25vID0gKGJsaykpCi0jZGVmaW5lIFhGU19CVUZfU0VU Q09VTlQoYnAsY250KQkoKGJwKS0+Yl9iY291bnQgPSAoY250KSkKKyNkZWZp bmUgWEZTX0JVRl9TRVRfQ09VTlQoYnAsY250KQkoKGJwKS0+Yl9iY291bnQg PSAoY250KSkKIAogI2RlZmluZSBYRlNfQlVGX0ZTUFJJVkFURShicCx0eXBl KQkoKHR5cGUpKGJwKS0+Yl9mc3ByaXZhdGUpCiAjZGVmaW5lIFhGU19CVUZf U0VUX0ZTUFJJVkFURShicCx2YWwpCShicCktPmJfZnNwcml2YXRlID0gKHZv aWQgKikodmFsKQoKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cnhm c3Byb2dzL2luY2x1ZGUvbGlieGxvZy5oCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQoKLS0tIGEveGZzcHJvZ3MvaW5jbHVkZS9saWJ4bG9nLmgJ MjAwNy0wNy0xMyAxMDozNTozOC4wMDAwMDAwMDAgKzEwMDAKKysrIGIveGZz cHJvZ3MvaW5jbHVkZS9saWJ4bG9nLmgJMjAwNy0wNy0xMiAxODoyOTowOC43 NDQ1NjI5NDcgKzEwMDAKQEAgLTQ0LDYgKzQ0LDggQEAgdHlwZWRlZiBzdHJ1 Y3QgbG9nIHsKIAlpbnQJCWxfZ3JhbnRfd3JpdGVfY3ljbGU7CS8qICovCiAJ aW50CQlsX2dyYW50X3dyaXRlX2J5dGVzOwkvKiAqLwogCXVpbnQJCWxfc2Vj dGJiX2xvZzsgICAvKiBsb2cyIG9mIHNlY3RvciBzaXplIGluIGJicyAqLwor CXVpbnQJCWxfc2VjdGJiX21hc2s7ICAvKiBzZWN0b3Igc2l6ZSAoaW4gQkJz KQorCQkJCQkgKiBhbGlnbm1lbnQgbWFzayAqLwogfSB4bG9nX3Q7CiAKICNp bmNsdWRlIDx4ZnMveGZzX2xvZ19yZWNvdmVyLmg+CkBAIC03OSwxMyArODEs NiBAQCBleHRlcm4gdm9pZCB4bG9nX3dhcm4oY2hhciAqZm10LC4uLik7CiBl eHRlcm4gdm9pZCB4bG9nX2V4aXQoY2hhciAqZm10LC4uLik7CiBleHRlcm4g dm9pZCB4bG9nX3BhbmljKGNoYXIgKmZtdCwuLi4pOwogCi0jZGVmaW5lIHhs b2dfZ2V0X2JwKGxvZyxiYnMpCWxpYnhmc19nZXRidWZyKHgubG9nZGV2LCAo eGZzX2RhZGRyX3QpLTEsIChiYnMpKQotI2RlZmluZSB4bG9nX3B1dF9icChi cCkJCWxpYnhmc19wdXRidWZyKGJwKQotI2RlZmluZSB4bG9nX2JyZWFkKGxv ZyxibGtubyxiYnMsYnApCVwKLQkobGlieGZzX3JlYWRidWZyKHgubG9nZGV2 LAlcCi0JCQkobG9nKS0+bF9sb2dCQnN0YXJ0KyhibGtubyksIGJwLCAoYmJz KSwgMSksIDApCi0jZGVmaW5lIHhsb2dfYWxpZ24obG9nLGJsa25vLG5iYmxr cyxicCkJWEZTX0JVRl9QVFIoYnApCi0KICNkZWZpbmUga21lbV96YWxsb2Mo c2l6ZSwgZm9vKQkJCWNhbGxvYyhzaXplLDEpCiAjZGVmaW5lIGttZW1fYWxs b2Moc2l6ZSwgZm9vKQkJCWNhbGxvYyhzaXplLDEpCiAjZGVmaW5lIGttZW1f ZnJlZShwdHIsIGZvbykJCQlmcmVlKHB0cikKQEAgLTk5LDYgKzk0LDEwIEBA IGV4dGVybiBpbnQJcHJpbnRfcmVjb3JkX2hlYWRlcjsKIC8qIGxpYnhmcyBw YXJhbWV0ZXJzICovCiBleHRlcm4gbGlieGZzX2luaXRfdAl4OwogCitleHRl cm4gc3RydWN0IHhmc19idWYgKnhsb2dfZ2V0X2JwKHhsb2dfdCAqLCBpbnQp OworZXh0ZXJuIHZvaWQJIHhsb2dfcHV0X2JwKHN0cnVjdCB4ZnNfYnVmICop OworZXh0ZXJuIGludAkgeGxvZ19icmVhZCh4bG9nX3QgKiwgeGZzX2RhZGRy X3QsIGludCwgc3RydWN0IHhmc19idWYgKik7CisKIGV4dGVybiBpbnQgIHhs b2dfZmluZF96ZXJvZWQoeGxvZ190ICpsb2csIHhmc19kYWRkcl90ICpibGtf bm8pOwogZXh0ZXJuIGludCAgeGxvZ19maW5kX2N5Y2xlX3N0YXJ0KHhsb2df dCAqbG9nLCB4ZnNfYnVmX3QgKmJwLAogCQl4ZnNfZGFkZHJfdCBmaXJzdF9i bGssIHhmc19kYWRkcl90ICpsYXN0X2JsaywgdWludCBjeWNsZSk7Cgo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0KeGZzcHJvZ3MvbGlieGxvZy94 ZnNfbG9nX3JlY292ZXIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KCi0tLSBhL3hmc3Byb2dzL2xpYnhsb2cveGZzX2xvZ19yZWNvdmVyLmMJ MjAwNy0wNy0xMyAxMDozNTozOC4wMDAwMDAwMDAgKzEwMDAKKysrIGIveGZz cHJvZ3MvbGlieGxvZy94ZnNfbG9nX3JlY292ZXIuYwkyMDA3LTA3LTEyIDE4 OjQzOjE3Ljk1ODA0Mzc1MiArMTAwMApAQCAtMjIsNiArMjIsODQgQEAKICNk ZWZpbmUgeGxvZ19jbGVhcl9zdGFsZV9ibG9ja3MobG9nLCB0YWlsX2xzbikJ CSgwKQogI2RlZmluZSB4ZnNfcmVhZG9ubHlfYnVmdGFyZyhidWZ0YXJnKQkJ CSgwKQogCisKKy8qCisgKiBTZWN0b3IgYWxpZ25lZCBidWZmZXIgcm91dGlu ZXMgZm9yIGJ1ZmZlciBjcmVhdGUvcmVhZC93cml0ZS9hY2Nlc3MKKyAqLwor CisjZGVmaW5lIFhMT0dfU0VDVE9SX1JPVU5EVVBfQkJDT1VOVChsb2csIGJi cykJXAorCSggKChsb2cpLT5sX3NlY3RiYl9tYXNrICYmIChiYnMgJiAobG9n KS0+bF9zZWN0YmJfbWFzaykpID8gXAorCSgoYmJzICsgKGxvZyktPmxfc2Vj dGJiX21hc2sgKyAxKSAmIH4obG9nKS0+bF9zZWN0YmJfbWFzaykgOiAoYmJz KSApCisjZGVmaW5lIFhMT0dfU0VDVE9SX1JPVU5ERE9XTl9CTEtOTyhsb2cs IGJubykJKChibm8pICYgfihsb2cpLT5sX3NlY3RiYl9tYXNrKQorCit4ZnNf YnVmX3QgKgoreGxvZ19nZXRfYnAoCisJeGxvZ190CQkqbG9nLAorCWludAkJ bnVtX2JibGtzKQoreworCUFTU0VSVChudW1fYmJsa3MgPiAwKTsKKworCWlm IChsb2ctPmxfc2VjdGJiX2xvZykgeworCQlpZiAobnVtX2JibGtzID4gMSkK KwkJCW51bV9iYmxrcyArPSBYTE9HX1NFQ1RPUl9ST1VORFVQX0JCQ09VTlQo bG9nLCAxKTsKKwkJbnVtX2JibGtzID0gWExPR19TRUNUT1JfUk9VTkRVUF9C QkNPVU5UKGxvZywgbnVtX2JibGtzKTsKKwl9CisJcmV0dXJuIGxpYnhmc19n ZXRidWZyKGxvZy0+bF9kZXYsICh4ZnNfZGFkZHJfdCktMSwgbnVtX2JibGtz KTsKK30KKwordm9pZAoreGxvZ19wdXRfYnAoCisJeGZzX2J1Zl90CSpicCkK K3sKKwlsaWJ4ZnNfcHV0YnVmcihicCk7Cit9CisKKworLyoKKyAqIG5iYmxr cyBzaG91bGQgYmUgdWludCwgYnV0IG9oIHdlbGwuICBKdXN0IHdhbnQgdG8g Y2F0Y2ggdGhhdCAzMi1iaXQgbGVuZ3RoLgorICovCitpbnQKK3hsb2dfYnJl YWQoCisJeGxvZ190CQkqbG9nLAorCXhmc19kYWRkcl90CWJsa19ubywKKwlp bnQJCW5iYmxrcywKKwl4ZnNfYnVmX3QJKmJwKQoreworCWlmIChsb2ctPmxf c2VjdGJiX2xvZykgeworCQlibGtfbm8gPSBYTE9HX1NFQ1RPUl9ST1VORERP V05fQkxLTk8obG9nLCBibGtfbm8pOworCQluYmJsa3MgPSBYTE9HX1NFQ1RP Ul9ST1VORFVQX0JCQ09VTlQobG9nLCBuYmJsa3MpOworCX0KKworCUFTU0VS VChuYmJsa3MgPiAwKTsKKwlBU1NFUlQoQkJUT0IobmJibGtzKSA8PSBYRlNf QlVGX1NJWkUoYnApKTsKKwlBU1NFUlQoYnApOworCisJWEZTX0JVRl9TRVRf QUREUihicCwgbG9nLT5sX2xvZ0JCc3RhcnQgKyBibGtfbm8pOworCVhGU19C VUZfU0VUX0NPVU5UKGJwLCBCQlRPQihuYmJsa3MpKTsKKworCXJldHVybiBs aWJ4ZnNfcmVhZGJ1ZnIobG9nLT5sX2RldiwgYmxrX25vLCBicCwgbmJibGtz LCAwKTsKK30KKworCitzdGF0aWMgeGZzX2NhZGRyX3QKK3hsb2dfYWxpZ24o CisJeGxvZ190CQkqbG9nLAorCXhmc19kYWRkcl90CWJsa19ubywKKwlpbnQJ CW5iYmxrcywKKwl4ZnNfYnVmX3QJKmJwKQoreworCXhmc19jYWRkcl90CXB0 cjsKKworCWlmICghbG9nLT5sX3NlY3RiYl9sb2cpCisJCXJldHVybiBYRlNf QlVGX1BUUihicCk7CisKKwlwdHIgPSBYRlNfQlVGX1BUUihicCkgKyBCQlRP QigoaW50KWJsa19ubyAmIGxvZy0+bF9zZWN0YmJfbWFzayk7CisJQVNTRVJU KFhGU19CVUZfU0laRShicCkgPj0KKwkJQkJUT0IobmJibGtzICsgKGJsa19u byAmIGxvZy0+bF9zZWN0YmJfbWFzaykpKTsKKwlyZXR1cm4gcHRyOworfQor CisKIC8qCiAgKiBUaGlzIHJvdXRpbmUgZmluZHMgKHRvIGFuIGFwcHJveGlt YXRpb24pIHRoZSBmaXJzdCBibG9jayBpbiB0aGUgcGh5c2ljYWwKICAqIGxv ZyB3aGljaCBjb250YWlucyB0aGUgZ2l2ZW4gY3ljbGUuICBJdCB1c2VzIGEg YmluYXJ5IHNlYXJjaCBhbGdvcml0aG0uCgo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KeGZzcHJvZ3MvcmVwYWlyL3BoYXNlMi5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQoKLS0tIGEveGZzcHJvZ3MvcmVwYWly L3BoYXNlMi5jCTIwMDctMDctMTMgMTA6MzU6MzguMDAwMDAwMDAwICsxMDAw CisrKyBiL3hmc3Byb2dzL3JlcGFpci9waGFzZTIuYwkyMDA3LTA3LTEyIDE4 OjQ1OjU1LjMwNTUyODU5MCArMTAwMApAQCAtNTAsNiArNTAsMTYgQEAgemVy b19sb2coeGZzX21vdW50X3QgKm1wKQogCWxvZy5sX2xvZ0JCc2l6ZSA9IHgu bG9nQkJzaXplOwogCWxvZy5sX2xvZ0JCc3RhcnQgPSB4LmxvZ0JCc3RhcnQ7 CiAJbG9nLmxfbXAgPSBtcDsKKwlpZiAoWEZTX1NCX1ZFUlNJT05fSEFTU0VD VE9SKCZtcC0+bV9zYikpIHsKKwkJbG9nLmxfc2VjdGJiX2xvZyA9IG1wLT5t X3NiLnNiX2xvZ3NlY3Rsb2cgLSBCQlNISUZUOworCQlBU1NFUlQobG9nLmxf c2VjdGJiX2xvZyA8PSBtcC0+bV9zZWN0YmJfbG9nKTsKKwkJLyogZm9yIGxh cmdlciBzZWN0b3Igc2l6ZXMsIG11c3QgaGF2ZSB2MiBvciBleHRlcm5hbCBs b2cgKi8KKwkJQVNTRVJUKGxvZy5sX3NlY3RiYl9sb2cgPT0gMCB8fAorCQkJ bG9nLmxfbG9nQkJzdGFydCA9PSAwIHx8CisJCQlYRlNfU0JfVkVSU0lPTl9I QVNMT0dWMigmbXAtPm1fc2IpKTsKKwkJQVNTRVJUKG1wLT5tX3NiLnNiX2xv Z3NlY3Rsb2cgPj0gQkJTSElGVCk7CisJfQorCWxvZy5sX3NlY3RiYl9tYXNr ID0gKDEgPDwgbG9nLmxfc2VjdGJiX2xvZykgLSAxOwogCiAJaWYgKChlcnJv ciA9IHhsb2dfZmluZF90YWlsKCZsb2csICZoZWFkX2JsaywgJnRhaWxfYmxr LCAwKSkpIHsKIAkJZG9fd2FybihfKCJ6ZXJvX2xvZzogY2Fubm90IGZpbmQg bG9nIGhlYWQvdGFpbCAiCgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KeGZzcHJvZ3MvcmVwYWlyL3hmc19yZXBhaXIuYwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KCi0tLSBhL3hmc3Byb2dzL3JlcGFpci94ZnNf cmVwYWlyLmMJMjAwNy0wNy0xMyAxMDozNTozOC4wMDAwMDAwMDAgKzEwMDAK KysrIGIveGZzcHJvZ3MvcmVwYWlyL3hmc19yZXBhaXIuYwkyMDA3LTA3LTEy IDE2OjE0OjEzLjM0NzAzODQ2MyArMTAwMApAQCAtNTAxLDcgKzUwMSw4IEBA IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogCX0KIAogCS8qIHByZXBh cmUgdGhlIG1vdW50IHN0cnVjdHVyZSAqLwotCXNicCA9IGxpYnhmc19yZWFk YnVmKHguZGRldiwgWEZTX1NCX0RBRERSLCAxLCAwKTsKKwlzYnAgPSBsaWJ4 ZnNfcmVhZGJ1Zih4LmRkZXYsIFhGU19TQl9EQUREUiwKKwkJCQkxIDw8IChY RlNfTUFYX1NFQ1RPUlNJWkVfTE9HIC0gQkJTSElGVCksIDApOwogCW1lbXNl dCgmeGZzX20sIDAsIHNpemVvZih4ZnNfbW91bnRfdCkpOwogCXNiID0gJnhm c19tLm1fc2I7CiAJbGlieGZzX3hsYXRlX3NiKFhGU19CVUZfUFRSKHNicCks IHNiLCAxLCBYRlNfU0JfQUxMX0JJVFMpOwpAQCAtNTE1LDYgKzUxNiw3IEBA IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogCQlleGl0KDEpOwogCX0K IAlsaWJ4ZnNfcHV0YnVmKHNicCk7CisJbGlieGZzX3B1cmdlYnVmKHNicCk7 CiAKIAkvKgogCSAqIHNldCBYRlMtaW5kZXBlbmRlbnQgc3RhdHVzIHZhcnMg ZnJvbSB0aGUgbW91bnQvc2Igc3RydWN0dXJlCg== ------------uxUULPiKOb4497tspFf8oZ-- From owner-xfs@oss.sgi.com Thu Jul 12 17:52:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jul 2007 17:52: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 l6D0pubm021834 for ; Thu, 12 Jul 2007 17:51:58 -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 KAA15135; Fri, 13 Jul 2007 10:51:53 +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 l6D0pqeW21850847; Fri, 13 Jul 2007 10:51:52 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6D0pNOq21851422; Fri, 13 Jul 2007 10:51:23 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 13 Jul 2007 10:51:23 +1000 From: David Chinner To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev Subject: Re: REVIEW: Make sure xfs_repair uses sector aligned I/O Message-ID: <20070713005123.GH31489@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 12147 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: 706 Lines: 26 On Fri, Jul 13, 2007 at 10:41:47AM +1000, Barry Naujok wrote: > Two places it didn't: > - reading the initial primary superblock > - checking the log > > The log checking fix was basically porting the kernel > xlog_bread/xlog_get_bp/xlog_align from the kernel and > setting up the log_t structure properly in Phase 2. > > The initial primary superblock read is now done > using the maximum supported sector size as once the > block is read and translated to another location, > it's discarded. Seems OK from a quick look of the code. Were you able to confirm that these are the only places we do non-sector sized I/O? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Jul 13 00:17:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jul 2007 00:17:44 -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 l6D7Hcbm002594 for ; Fri, 13 Jul 2007 00:17:40 -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 RAA25497; Fri, 13 Jul 2007 17:17:30 +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 l6D7HTeW21258165; Fri, 13 Jul 2007 17:17:30 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id l6D7HSlR22013785; Fri, 13 Jul 2007 17:17:28 +1000 (AEST) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 13 Jul 2007 17:17:28 +1000 From: David Chinner To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: xfsqa 144 is failing now Message-ID: <20070713071728.GM31489@sgi.com> References: <20070712150431.GA3763@infradead.org> <20070712222304.GA31489@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070712222304.GA31489@sgi.com> 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: 12148 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: 1159 Lines: 34 On Fri, Jul 13, 2007 at 08:23:05AM +1000, David Chinner wrote: > On Thu, Jul 12, 2007 at 04:04:31PM +0100, Christoph Hellwig wrote: > > I'm trying to fix up dmapi for the patch that uses filldir internally, > > and 144 is the xfsqa test for this functionality. It worked fine a > > few weeks ago when I started that work but fails with plain TOT linux-xfs > > now with errors like: ..... > > > > does anyone have an idea what might be causing this? > > Not yet - AFAIK we're only seeing it on i386 ATM, and we only noticed it in > the past couple of days. Nobody has had a chance to look at it yet. I don't > think dmapi has been tested regularly on i386 so I'm not sure when the problem > first appeared yet. > > > The only recent changes to xfs_dm.c are the hole punching fixes which > > seem rather unrelated. > > *nod* > > Given the expected output, I wouldn't be surprised if we've got > some kind of 32/64 bit problem here.... Just to confirm - test 144 is passing reliably on ia64 with a TOT kernel and xfstests, so it's likely to be something specific to i386. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Jul 13 05:38:04 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jul 2007 05:38:09 -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_99,J_CHICKENPOX_43, J_CHICKENPOX_45,J_CHICKENPOX_52,J_CHICKENPOX_54 autolearn=no version=3.2.0-pre1-r499012 Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l6DCc3bm023329 for ; Fri, 13 Jul 2007 05:38:04 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6DCc5bo031873 for ; Fri, 13 Jul 2007 08:38:05 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6DCc50P162284 for ; Fri, 13 Jul 2007 06:38:05 -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 l6DCc4qZ009350 for ; Fri, 13 Jul 2007 06:38:05 -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 l6DCc2qa009188; Fri, 13 Jul 2007 06:38:03 -0600 Received: from amitarora.in.ibm.com (localhost.localdomain [127.0.0.1]) by amitarora.in.ibm.com (Postfix) with ESMTP id EB9A629F6C0; Fri, 13 Jul 2007 18:08:18 +0530 (IST) Received: (from amit@localhost) by amitarora.in.ibm.com (8.13.1/8.13.1/Submit) id l6DCcGC3021067; Fri, 13 Jul 2007 18:08:16 +0530 Date: Fri, 13 Jul 2007 18:08:16 +0530 From: "Amit K. Arora" To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Cc: xfs@oss.sgi.com, michael.kerrisk@gmx.net, tytso@mit.edu, cmm@us.ibm.com, suparna@in.ibm.com, adilger@clusterfs.com, dgc@sgi.com Subject: [PATCH 0/6][TAKE7] fallocate system call Message-ID: <20070713123816.GA18000@amitarora.in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: 12149 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: 7098 Lines: 261 This is the latest fallocate patchset and is based on 2.6.22. * Following are the changes from TAKE6: 1) We now just have two modes (and no deallocation modes). 2) Updated the man page 3) Added a new patch submitted by David P. Quigley (Patch 3/6). 4) Used EXT_INIT_MAX_LEN instead of 0x8000 in Patch 6/6. 5) Included below in the end is a small testcase to test fallocate. * Following are the changes from TAKE5 to TAKE6: 1) Rebased to 2.6.22 2) Added compat wrapper for x86_64 3) Dropped s390 and ia64 patches, since the platform maintaners can add the support for fallocate once it is in mainline. 4) Added a change suggested by Andreas for better extent-to-group alignment in ext4 (Patch 6/6). Please refer following post: 5) Renamed mode flags and values from "FA_" to "FALLOC_" 6) Added manpage (updated version of the one initially submitted by David Chinner). Todos: ----- 1> Implementation on other architectures (other than i386, x86_64, and ppc64). s390(x) and ia64 patches are ready and will be pushed by platform maintaners when the fallocate is in mainline. 2> A generic file system operation to handle fallocate (generic_fallocate), for filesystems that do _not_ have the fallocate inode operation implemented. 3> Changes to glibc, a) to support fallocate() system call b) to make posix_fallocate() and posix_fallocate64() call fallocate() 4> Patch to e2fsprogs to recognize and display uninitialized extents. Following patches follow: Patch 1/6 : manpage for fallocate Patch 2/6 : fallocate() implementation in i386, x86_64 and powerpc Patch 3/6 : revalidate write permissions for fallocate Patch 4/6 : ext4: fallocate support in ext4 Patch 5/6 : ext4: write support for preallocated blocks Patch 6/6 : ext4: change for better extent-to-group alignment Note: Attached below is a small testcase to test fallocate. The __NR_fallocate will need to be changed depending on the system call number in the kernel (it may get changed due to merge) and also depending on the architecture. -- Regards, Amit Arora #include #include #include #include #include #include #include #define VERBOSE 0 #define __NR_fallocate 324 #define FALLOC_FL_KEEP_SIZE 0x01 #define FALLOC_ALLOCATE 0x0 #define FALLOC_RESV_SPACE FALLOC_FL_KEEP_SIZE int do_fallocate(int fd, int mode, loff_t offset, loff_t len) { int ret; if (VERBOSE) printf("Trying to preallocate blocks (offset=%llu, len=%llu)\n", offset, len); ret = syscall(__NR_fallocate, fd, mode, offset, len); if (ret <0) { printf("SYSCALL: received error %d, ret=%d\n", errno, ret); close(fd); return(1); } if (VERBOSE) printf("fallocate system call succedded ! ret=%d\n", ret); return ret; } int test_fallocate(int fd, int mode, loff_t offset, loff_t len) { int ret, blocks; struct stat statbuf1, statbuf2; fstat(fd, &statbuf1); ret = do_fallocate(fd, mode, offset, len); fstat(fd, &statbuf2); /* check file size after preallocation */ if (mode == FALLOC_ALLOCATE) { if (!ret && statbuf1.st_size < (offset + len) && statbuf2.st_size != (offset + len)) { printf("Error: fallocate succeeded, but the file size did not " "change, where it should have!\n"); ret = 1; } } else if (statbuf1.st_size != statbuf2.st_size) { printf("Error : File size changed, when it should not have!\n"); ret = 1; } blocks = ((statbuf2.st_blocks - statbuf1.st_blocks) * 512)/ statbuf2.st_blksize; /* Print report */ printf("# FALLOCATE TEST REPORT #\n"); printf("\tNew blocks preallocated = %d.\n", blocks); printf("\tNumber of bytes preallocated = %d\n", blocks * statbuf2.st_blksize); printf("\tOld file size = %d, New file size %d.\n", statbuf1.st_size, statbuf2.st_size); printf("\tOld num blocks = %d, New num blocks %d.\n", (statbuf1.st_blocks * 512)/1024, (statbuf2.st_blocks * 512)/1024); return ret; } int do_write(int fd, loff_t offset, loff_t len) { int ret; char *buf; buf = (char *)malloc(len); if (!buf) { printf("error: malloc failed.\n"); return(-1); } if (VERBOSE) printf("Trying to write to file (offset=%llu, len=%llu)\n", offset, len); ret = lseek(fd, offset, SEEK_SET); if (ret != offset) { printf("lseek() failed error=%d, ret=%d\n", errno, ret); close(fd); return(-1); } ret = write(fd, buf, len); if (ret != len) { printf("write() failed error=%d, ret=%d\n", errno, ret); close(fd); return(-1); } if (VERBOSE) printf("Write succedded ! Written %llu bytes ret=%d\n", len, ret); return ret; } int test_write(int fd, loff_t offset, loff_t len) { int ret; ret = do_write(fd, offset, len); printf("# WRITE TEST REPORT #\n"); if (ret > 0) printf("\t written %d bytes.\n", ret); else printf("\t write operation failed!\n"); if (ret > 0) return 0; else return 1; } void usage(char **argv) { printf("\n%s