From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?) Date: Tue, 19 Apr 2011 17:45:38 +1000 Message-ID: <20110419074538.GG23985@dastard> References: <20110415000940.GL21395@dastard> <76FFF648-CA02-494B-A862-566C66A8CB82@dilger.ca> <20110416005040.GP21395@dastard> <4EEEA16E-1FDB-4430-A372-8F8701196E4C@mit.edu> <20110418004040.GS21395@dastard> <6C89E159-A5F6-4A06-A3D2-273BE4CFB9B5@dilger.ca> <20110419034455.GB23985@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andreas Dilger , Theodore Tso , Eric Sandeen , xfs-oss , "coreutils@gnu.org" , "linux-ext4@vger.kernel.org" , =?iso-8859-1?Q?P=E1draig?= Brady , Markus Trippelsdorf To: Yongqiang Yang Return-path: Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:53521 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751911Ab1DSHpv (ORCPT ); Tue, 19 Apr 2011 03:45:51 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org List-ID: On Tue, Apr 19, 2011 at 02:53:20PM +0800, Yongqiang Yang wrote: > On Tue, Apr 19, 2011 at 11:44 AM, Dave Chinner = wrote: > > On Tue, Apr 19, 2011 at 09:58:15AM +0800, Yongqiang Yang wrote: > >> On Mon, Apr 18, 2011 at 10:45 AM, Andreas Dilger wrote: > >> > On 2011-04-17, at 6:40 PM, Dave Chinner wr= ote: > >> > > >> > On Sat, Apr 16, 2011 at 08:21:28AM -0400, Theodore Tso wrote: > >> > > >> > On Apr 16, 2011, at 1:11 AM, Andreas Dilger wrote: > >> > > >> > In that case, it means cp should just always use FIEMAP_FLAG_SYN= C, which is > >> > fine. > >> > > >> > Except that if someone is copying a large delay allocated file, = it will > >> > cause > >> > > >> > the file to immediately snapped to disk, which might not be the = greatest > >> > > >> > thing in the world. > >> > > >> > Obvious workaround - if the initial fiemap call shows unwritten > >> > extents, redo it with the sync flag set. Though that assume=D1=95= that > >> > you can trust things like delalloc extents to only cover the ran= ge > >> > that valid data exists in. Which, of course, you can't assume, > >> > either. :/ > >> > > >> > Always passing=C2=A0FIEMAP_FLAG_SYNC is fine in this case. It sh= ould only do > >> > anything if there is unwritten data, which is the only case we a= re concerned > >> > with at this point. =C2=A0In any case, this is a simple solution= for coreutils > >> > until such a time that a more complex solution is added in the k= ernel (if > >> > ever). > >> > > >> > Christoph is write, SEEK_HOLE and SEEK_DATA are > >> > > >> > a much better API for what cp woulld lke to do. =C2=A0Unfortunat= ely it hasn't > >> > > >> > been implemented yet in the VFS... > >> > > >> > Agreed, SEEK_HOLE/SEEK_DATA is the right way to solve this probl= em. > >> > > >> > I don't see how this will change the problem in any meaningful w= ay. There > >> > will still need to be code that is traversing the on-disk mappin= g, and also > >> > keeping it coherent with unwritten data in the page cache. > >> > >> It seems that we are being messed up by page cache and disk. > >> Unwritten flag returned from FIEMAP indicates blocks on disk are n= ot > >> written, but it does not say if there is data in page cache. =C2=A0= So > >> FIEMAP itself just tells user the map on disk. =C2=A0However there= is an > >> exception for delayed allocation, =C2=A0FIEMAP tells users the dat= a is in > >> page cache. > > > > No, FIEMAP does not tell the user there is data in the page cache. > > It tells there user there is a delayed allocation extent. For XFS, = a > > delayed allocation extent can cover a range _greater_ than there is > > data in the page cache - we do allocation allignment, speculative > > allocation and other tricks to avoid fragmentation via > > delayed allocation. When XFSs says there is a delalloc extent, it i= s > > simply showing the in-memory representation of the extent. if you > > want to know where the data in the page cache actually is, you need > > to sync the file to disk to get those ranges converted to real > > extents. This is how xfs_bmap has worked for 15 years.... > > > >> Maybe FIEMAP should return all known messages for unwritten extent= , if > >> unwritten data exists in page cache, FIEMAP should let users know = that > >> data is in page cache and space on disk has been preallocated, but > >> data has not been flushed into disk. =C2=A0Actually, delayed alloc= ation has > >> done like this. Then user-space applications can determine how to = do. > >> Taking cp as an example, it will copy from page cache rather ignor= e > >> it. > > > > Once again, FIEMAP is for showing the filesystem's current extent > > state, not the page cache state. Ext4 may implement FIEMAP by doing > > page cache walks, but that is a filesystem specific implementation > > detail. > > > >> We need a definite definition for FIEMAP, in other words, it tells > >> users map on disk or both disk and page cache. > > > > We already have a definition - and it has nothing to do with the > > page cache state. > > > >> If the former one is taken, then FIEMAP should not consider > >> delayed allocation. > > > > Not at all. the delayed allocation extent is a first class extent > > type in XFS and it is reported directly from the extent list. Your > > viewpoint is very ext4-specific and ignores the fact that other > > filesystems were doing this sort of mapping long before even ext3 > > (let alone ext4) was a glint in the designer's eye.... > > > >> otherwise, FIEMAP should return all known messages for unwritten c= ase > >> like delayed allocation. > > > > See my previous comments about extents being unwritten until data i= s > > physically written to them. > Understood, thank you for your explanation. >=20 > Ok. Let's look at it from a higher view. What you described about > extent state is specific to xfs. >=20 > I think there are 2 ways to provide a definite definition for FIEMAP > for all filesystems: >=20 > 1. FIEMAP returns extent state on disk. > 2. FIEMAP returns extent both in memory and on disk. You are *not listening*. There is no #2. FIEMAP returns the extent state _on disk_ at the time of the call. If you want it to reflect the in-memory state at the time of the call (for data or metadata), you *must* use the the SYNC flag to convert that in-memory state to on-disk state, which FIEMAP then reports just fine. Cheers, Dave. --=20 Dave Chinner david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id p3J7gQrQ026762 for ; Tue, 19 Apr 2011 02:42:26 -0500 Received: from ipmail06.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4A1C714F26F4 for ; Tue, 19 Apr 2011 00:45:50 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id UAb09Ba0cqFYr1K7 for ; Tue, 19 Apr 2011 00:45:50 -0700 (PDT) Date: Tue, 19 Apr 2011 17:45:38 +1000 From: Dave Chinner Subject: Re: Files full of zeros with coreutils-8.11 and xfs (FIEMAP related?) Message-ID: <20110419074538.GG23985@dastard> References: <20110415000940.GL21395@dastard> <76FFF648-CA02-494B-A862-566C66A8CB82@dilger.ca> <20110416005040.GP21395@dastard> <4EEEA16E-1FDB-4430-A372-8F8701196E4C@mit.edu> <20110418004040.GS21395@dastard> <6C89E159-A5F6-4A06-A3D2-273BE4CFB9B5@dilger.ca> <20110419034455.GB23985@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xfs-bounces@oss.sgi.com Errors-To: xfs-bounces@oss.sgi.com To: Yongqiang Yang Cc: Andreas Dilger , Theodore Tso , Eric Sandeen , xfs-oss , "coreutils@gnu.org" , "linux-ext4@vger.kernel.org" , =?iso-8859-1?Q?P=E1draig?= Brady , Markus Trippelsdorf T24gVHVlLCBBcHIgMTksIDIwMTEgYXQgMDI6NTM6MjBQTSArMDgwMCwgWW9uZ3FpYW5nIFlhbmcg d3JvdGU6Cj4gT24gVHVlLCBBcHIgMTksIDIwMTEgYXQgMTE6NDQgQU0sIERhdmUgQ2hpbm5lciA8 ZGF2aWRAZnJvbW9yYml0LmNvbT4gd3JvdGU6Cj4gPiBPbiBUdWUsIEFwciAxOSwgMjAxMSBhdCAw OTo1ODoxNUFNICswODAwLCBZb25ncWlhbmcgWWFuZyB3cm90ZToKPiA+PiBPbiBNb24sIEFwciAx OCwgMjAxMSBhdCAxMDo0NSBBTSwgQW5kcmVhcyBEaWxnZXIgPGFkaWxnZXJAZGlsZ2VyLmNhPiB3 cm90ZToKPiA+PiA+IE9uIDIwMTEtMDQtMTcsIGF0IDY6NDAgUE0sIERhdmUgQ2hpbm5lciA8ZGF2 aWRAZnJvbW9yYml0LmNvbT4gd3JvdGU6Cj4gPj4gPgo+ID4+ID4gT24gU2F0LCBBcHIgMTYsIDIw MTEgYXQgMDg6MjE6MjhBTSAtMDQwMCwgVGhlb2RvcmUgVHNvIHdyb3RlOgo+ID4+ID4KPiA+PiA+ IE9uIEFwciAxNiwgMjAxMSwgYXQgMToxMSBBTSwgQW5kcmVhcyBEaWxnZXIgd3JvdGU6Cj4gPj4g Pgo+ID4+ID4gSW4gdGhhdCBjYXNlLCBpdCBtZWFucyBjcCBzaG91bGQganVzdCBhbHdheXMgdXNl IEZJRU1BUF9GTEFHX1NZTkMsIHdoaWNoIGlzCj4gPj4gPiBmaW5lLgo+ID4+ID4KPiA+PiA+IEV4 Y2VwdCB0aGF0IGlmIHNvbWVvbmUgaXMgY29weWluZyBhIGxhcmdlIGRlbGF5IGFsbG9jYXRlZCBm aWxlLCBpdCB3aWxsCj4gPj4gPiBjYXVzZQo+ID4+ID4KPiA+PiA+IHRoZSBmaWxlIHRvIGltbWVk aWF0ZWx5IHNuYXBwZWQgdG8gZGlzaywgd2hpY2ggbWlnaHQgbm90IGJlIHRoZSBncmVhdGVzdAo+ ID4+ID4KPiA+PiA+IHRoaW5nIGluIHRoZSB3b3JsZC4KPiA+PiA+Cj4gPj4gPiBPYnZpb3VzIHdv cmthcm91bmQgLSBpZiB0aGUgaW5pdGlhbCBmaWVtYXAgY2FsbCBzaG93cyB1bndyaXR0ZW4KPiA+ PiA+IGV4dGVudHMsIHJlZG8gaXQgd2l0aCB0aGUgc3luYyBmbGFnIHNldC4gVGhvdWdoIHRoYXQg YXNzdW1l0ZUgdGhhdAo+ID4+ID4geW91IGNhbiB0cnVzdCB0aGluZ3MgbGlrZSBkZWxhbGxvYyBl eHRlbnRzIHRvIG9ubHkgY292ZXIgdGhlIHJhbmdlCj4gPj4gPiB0aGF0IHZhbGlkIGRhdGEgZXhp c3RzIGluLiBXaGljaCwgb2YgY291cnNlLCB5b3UgY2FuJ3QgYXNzdW1lLAo+ID4+ID4gZWl0aGVy LiA6Lwo+ID4+ID4KPiA+PiA+IEFsd2F5cyBwYXNzaW5nwqBGSUVNQVBfRkxBR19TWU5DIGlzIGZp bmUgaW4gdGhpcyBjYXNlLiBJdCBzaG91bGQgb25seSBkbwo+ID4+ID4gYW55dGhpbmcgaWYgdGhl cmUgaXMgdW53cml0dGVuIGRhdGEsIHdoaWNoIGlzIHRoZSBvbmx5IGNhc2Ugd2UgYXJlIGNvbmNl cm5lZAo+ID4+ID4gd2l0aCBhdCB0aGlzIHBvaW50LiDCoEluIGFueSBjYXNlLCB0aGlzIGlzIGEg c2ltcGxlIHNvbHV0aW9uIGZvciBjb3JldXRpbHMKPiA+PiA+IHVudGlsIHN1Y2ggYSB0aW1lIHRo YXQgYSBtb3JlIGNvbXBsZXggc29sdXRpb24gaXMgYWRkZWQgaW4gdGhlIGtlcm5lbCAoaWYKPiA+ PiA+IGV2ZXIpLgo+ID4+ID4KPiA+PiA+IENocmlzdG9waCBpcyB3cml0ZSwgU0VFS19IT0xFIGFu ZCBTRUVLX0RBVEEgYXJlCj4gPj4gPgo+ID4+ID4gYSBtdWNoIGJldHRlciBBUEkgZm9yIHdoYXQg Y3Agd291bGxkIGxrZSB0byBkby4gwqBVbmZvcnR1bmF0ZWx5IGl0IGhhc24ndAo+ID4+ID4KPiA+ PiA+IGJlZW4gaW1wbGVtZW50ZWQgeWV0IGluIHRoZSBWRlMuLi4KPiA+PiA+Cj4gPj4gPiBBZ3Jl ZWQsIFNFRUtfSE9MRS9TRUVLX0RBVEEgaXMgdGhlIHJpZ2h0IHdheSB0byBzb2x2ZSB0aGlzIHBy b2JsZW0uCj4gPj4gPgo+ID4+ID4gSSBkb24ndCBzZWUgaG93IHRoaXMgd2lsbCBjaGFuZ2UgdGhl IHByb2JsZW0gaW4gYW55IG1lYW5pbmdmdWwgd2F5LiBUaGVyZQo+ID4+ID4gd2lsbCBzdGlsbCBu ZWVkIHRvIGJlIGNvZGUgdGhhdCBpcyB0cmF2ZXJzaW5nIHRoZSBvbi1kaXNrIG1hcHBpbmcsIGFu ZCBhbHNvCj4gPj4gPiBrZWVwaW5nIGl0IGNvaGVyZW50IHdpdGggdW53cml0dGVuIGRhdGEgaW4g dGhlIHBhZ2UgY2FjaGUuCj4gPj4KPiA+PiBJdCBzZWVtcyB0aGF0IHdlIGFyZSBiZWluZyBtZXNz ZWQgdXAgYnkgcGFnZSBjYWNoZSBhbmQgZGlzay4KPiA+PiBVbndyaXR0ZW4gZmxhZyByZXR1cm5l ZCBmcm9tIEZJRU1BUCBpbmRpY2F0ZXMgYmxvY2tzIG9uIGRpc2sgYXJlIG5vdAo+ID4+IHdyaXR0 ZW4sIGJ1dCBpdCBkb2VzIG5vdCBzYXkgaWYgdGhlcmUgaXMgZGF0YSBpbiBwYWdlIGNhY2hlLiDC oFNvCj4gPj4gRklFTUFQIGl0c2VsZiBqdXN0IHRlbGxzIHVzZXIgdGhlIG1hcCBvbiBkaXNrLiDC oEhvd2V2ZXIgdGhlcmUgaXMgYW4KPiA+PiBleGNlcHRpb24gZm9yIGRlbGF5ZWQgYWxsb2NhdGlv biwgwqBGSUVNQVAgdGVsbHMgdXNlcnMgdGhlIGRhdGEgaXMgaW4KPiA+PiBwYWdlIGNhY2hlLgo+ ID4KPiA+IE5vLCBGSUVNQVAgZG9lcyBub3QgdGVsbCB0aGUgdXNlciB0aGVyZSBpcyBkYXRhIGlu IHRoZSBwYWdlIGNhY2hlLgo+ID4gSXQgdGVsbHMgdGhlcmUgdXNlciB0aGVyZSBpcyBhIGRlbGF5 ZWQgYWxsb2NhdGlvbiBleHRlbnQuIEZvciBYRlMsIGEKPiA+IGRlbGF5ZWQgYWxsb2NhdGlvbiBl eHRlbnQgY2FuIGNvdmVyIGEgcmFuZ2UgX2dyZWF0ZXJfIHRoYW4gdGhlcmUgaXMKPiA+IGRhdGEg aW4gdGhlIHBhZ2UgY2FjaGUgLSB3ZSBkbyBhbGxvY2F0aW9uIGFsbGlnbm1lbnQsIHNwZWN1bGF0 aXZlCj4gPiBhbGxvY2F0aW9uIGFuZCBvdGhlciB0cmlja3MgdG8gYXZvaWQgZnJhZ21lbnRhdGlv biB2aWEKPiA+IGRlbGF5ZWQgYWxsb2NhdGlvbi4gV2hlbiBYRlNzIHNheXMgdGhlcmUgaXMgYSBk ZWxhbGxvYyBleHRlbnQsIGl0IGlzCj4gPiBzaW1wbHkgc2hvd2luZyB0aGUgaW4tbWVtb3J5IHJl cHJlc2VudGF0aW9uIG9mIHRoZSBleHRlbnQuIGlmIHlvdQo+ID4gd2FudCB0byBrbm93IHdoZXJl IHRoZSBkYXRhIGluIHRoZSBwYWdlIGNhY2hlIGFjdHVhbGx5IGlzLCB5b3UgbmVlZAo+ID4gdG8g c3luYyB0aGUgZmlsZSB0byBkaXNrIHRvIGdldCB0aG9zZSByYW5nZXMgY29udmVydGVkIHRvIHJl YWwKPiA+IGV4dGVudHMuIFRoaXMgaXMgaG93IHhmc19ibWFwIGhhcyB3b3JrZWQgZm9yIDE1IHll YXJzLi4uLgo+ID4KPiA+PiBNYXliZSBGSUVNQVAgc2hvdWxkIHJldHVybiBhbGwga25vd24gbWVz c2FnZXMgZm9yIHVud3JpdHRlbiBleHRlbnQsIGlmCj4gPj4gdW53cml0dGVuIGRhdGEgZXhpc3Rz IGluIHBhZ2UgY2FjaGUsIEZJRU1BUCBzaG91bGQgbGV0IHVzZXJzIGtub3cgdGhhdAo+ID4+IGRh dGEgaXMgaW4gcGFnZSBjYWNoZSBhbmQgc3BhY2Ugb24gZGlzayBoYXMgYmVlbiBwcmVhbGxvY2F0 ZWQsIGJ1dAo+ID4+IGRhdGEgaGFzIG5vdCBiZWVuIGZsdXNoZWQgaW50byBkaXNrLiDCoEFjdHVh bGx5LCBkZWxheWVkIGFsbG9jYXRpb24gaGFzCj4gPj4gZG9uZSBsaWtlIHRoaXMuIFRoZW4gdXNl ci1zcGFjZSBhcHBsaWNhdGlvbnMgY2FuIGRldGVybWluZSBob3cgdG8gZG8uCj4gPj4gVGFraW5n IGNwIGFzIGFuIGV4YW1wbGUsIGl0IHdpbGwgY29weSBmcm9tIHBhZ2UgY2FjaGUgcmF0aGVyIGln bm9yZQo+ID4+IGl0Lgo+ID4KPiA+IE9uY2UgYWdhaW4sIEZJRU1BUCBpcyBmb3Igc2hvd2luZyB0 aGUgZmlsZXN5c3RlbSdzIGN1cnJlbnQgZXh0ZW50Cj4gPiBzdGF0ZSwgbm90IHRoZSBwYWdlIGNh Y2hlIHN0YXRlLiBFeHQ0IG1heSBpbXBsZW1lbnQgRklFTUFQIGJ5IGRvaW5nCj4gPiBwYWdlIGNh Y2hlIHdhbGtzLCBidXQgdGhhdCBpcyBhIGZpbGVzeXN0ZW0gc3BlY2lmaWMgaW1wbGVtZW50YXRp b24KPiA+IGRldGFpbC4KPiA+Cj4gPj4gV2UgbmVlZCBhIGRlZmluaXRlIGRlZmluaXRpb24gZm9y IEZJRU1BUCwgaW4gb3RoZXIgd29yZHMsIGl0IHRlbGxzCj4gPj4gdXNlcnMgbWFwIG9uIGRpc2sg b3IgYm90aCBkaXNrIGFuZCBwYWdlIGNhY2hlLgo+ID4KPiA+IFdlIGFscmVhZHkgaGF2ZSBhIGRl ZmluaXRpb24gLSBhbmQgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUKPiA+IHBhZ2UgY2Fj aGUgc3RhdGUuCj4gPgo+ID4+IElmIHRoZSBmb3JtZXIgb25lIGlzIHRha2VuLCB0aGVuIEZJRU1B UCBzaG91bGQgbm90IGNvbnNpZGVyCj4gPj4gZGVsYXllZCBhbGxvY2F0aW9uLgo+ID4KPiA+IE5v dCBhdCBhbGwuIHRoZSBkZWxheWVkIGFsbG9jYXRpb24gZXh0ZW50IGlzIGEgZmlyc3QgY2xhc3Mg ZXh0ZW50Cj4gPiB0eXBlIGluIFhGUyBhbmQgaXQgaXMgcmVwb3J0ZWQgZGlyZWN0bHkgZnJvbSB0 aGUgZXh0ZW50IGxpc3QuIFlvdXIKPiA+IHZpZXdwb2ludCBpcyB2ZXJ5IGV4dDQtc3BlY2lmaWMg YW5kIGlnbm9yZXMgdGhlIGZhY3QgdGhhdCBvdGhlcgo+ID4gZmlsZXN5c3RlbXMgd2VyZSBkb2lu ZyB0aGlzIHNvcnQgb2YgbWFwcGluZyBsb25nIGJlZm9yZSBldmVuIGV4dDMKPiA+IChsZXQgYWxv bmUgZXh0NCkgd2FzIGEgZ2xpbnQgaW4gdGhlIGRlc2lnbmVyJ3MgZXllLi4uLgo+ID4KPiA+PiBv dGhlcndpc2UsIEZJRU1BUCBzaG91bGQgcmV0dXJuIGFsbCBrbm93biBtZXNzYWdlcyBmb3IgdW53 cml0dGVuIGNhc2UKPiA+PiBsaWtlIGRlbGF5ZWQgYWxsb2NhdGlvbi4KPiA+Cj4gPiBTZWUgbXkg cHJldmlvdXMgY29tbWVudHMgYWJvdXQgZXh0ZW50cyBiZWluZyB1bndyaXR0ZW4gdW50aWwgZGF0 YSBpcwo+ID4gcGh5c2ljYWxseSB3cml0dGVuIHRvIHRoZW0uCj4gVW5kZXJzdG9vZCwgdGhhbmsg eW91IGZvciB5b3VyIGV4cGxhbmF0aW9uLgo+IAo+IE9rLiAgTGV0J3MgbG9vayBhdCBpdCBmcm9t IGEgaGlnaGVyIHZpZXcuICBXaGF0IHlvdSBkZXNjcmliZWQgYWJvdXQKPiBleHRlbnQgc3RhdGUg aXMgc3BlY2lmaWMgdG8geGZzLgo+IAo+IEkgdGhpbmsgdGhlcmUgYXJlIDIgd2F5cyB0byBwcm92 aWRlIGEgZGVmaW5pdGUgZGVmaW5pdGlvbiBmb3IgRklFTUFQCj4gZm9yIGFsbCBmaWxlc3lzdGVt czoKPiAKPiAxLiBGSUVNQVAgcmV0dXJucyBleHRlbnQgc3RhdGUgb24gZGlzay4KPiAyLiBGSUVN QVAgcmV0dXJucyBleHRlbnQgYm90aCBpbiBtZW1vcnkgYW5kIG9uIGRpc2suCgpZb3UgYXJlICpu b3QgbGlzdGVuaW5nKi4gVGhlcmUgaXMgbm8gIzIuIEZJRU1BUCByZXR1cm5zIHRoZSBleHRlbnQK c3RhdGUgX29uIGRpc2tfIGF0IHRoZSB0aW1lIG9mIHRoZSBjYWxsLiBJZiB5b3Ugd2FudCBpdCB0 byByZWZsZWN0CnRoZSBpbi1tZW1vcnkgc3RhdGUgYXQgdGhlIHRpbWUgb2YgdGhlIGNhbGwgKGZv ciBkYXRhIG9yIG1ldGFkYXRhKSwKeW91ICptdXN0KiB1c2UgdGhlIHRoZSBTWU5DIGZsYWcgdG8g Y29udmVydCB0aGF0IGluLW1lbW9yeSBzdGF0ZSB0bwpvbi1kaXNrIHN0YXRlLCB3aGljaCBGSUVN QVAgdGhlbiByZXBvcnRzIGp1c3QgZmluZS4KCkNoZWVycywKCkRhdmUuCi0tIApEYXZlIENoaW5u ZXIKZGF2aWRAZnJvbW9yYml0LmNvbQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KeGZzIG1haWxpbmcgbGlzdAp4ZnNAb3NzLnNnaS5jb20KaHR0cDovL29z cy5zZ2kuY29tL21haWxtYW4vbGlzdGluZm8veGZzCg==