From owner-freebsd-hackers@freebsd.org Wed Sep 23 01:18:21 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6204A3E7755 for ; Wed, 23 Sep 2020 01:18:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660084.outbound.protection.outlook.com [40.107.66.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bx0g03yqhz41yS; Wed, 23 Sep 2020 01:18:20 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KYAGibQTi9/NifEMNU7tm7Nz9dE5OJc5nJoAqDMORufQ+QiI+0hfh58E0/Ao9UjExdQQJD4xLXOr6taRKQV65AGrcNQdHTSBAatFVqSSJbCDTX/AJIIRWl8qBnDEOyiz41eIELyoVHRsVIeDFRHwD8ik2B9q8D1p0Y5ZJpvSc6nb+mXX3zmp6R233ARZ6s/qbwJYWtKv+YN1tHVqpwmhy2JF2RVB7/FT9hEUgqPZhaqnH61caPxClt1gBO47jZAvryQraWHVORPVs1fzjsIN1qOrD3ZZIPieHj0bLXqvVT2ZZZiFRoS9rclMPyHzQFhaSu0EdXOeXcksmllA08DMaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eiZ1Ji+HG9wgUD5ucCdZ8YNFTWoAy2bXzxICx4tybUo=; b=hGJd6Szr6F/kn7yEKVd6HrEFthFWb2OcetoB7BWP+m93Lg1TLVJ0Yw6icgmDOhmK7jx/FBN/9Mcdce1QwRC1oCIIdLsXASY9CN/VPxlQYZ+FoShw51HJXtkqcyQ0WnHyHZQMHGnEYAp1tWff0Je/X1p8ioztvOh5ouUUzVS1pXVQ6aMZsWKHredwBrQ2ZyAnyjQrAnQFbKulbWbsHPHNevkhGhQjSLIsPI/Qh61e92UXu+lVUatNEVAWY3iF36jst8px7QClA2RuZyCIZfstC9XvmNhWC2rMoRZvWK4uoZ5akd8Cmcwo4fALVY/wU9+71bRMg719vdSTjn22/wuKlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eiZ1Ji+HG9wgUD5ucCdZ8YNFTWoAy2bXzxICx4tybUo=; b=wYzha3amS+ueBbrSrhwA4IeoMHLTKzfZ7vFll0Cue13zPusK/37CDAJfTGNGx3LajHmSnCYA8S7ABvTqq7jAvXFupHva87TvQ0+fuDYlOUXs1EGHYR/y35ZR/xLyDi5BwQvj/1WpwhipEhUKXAxXqGSj67nSKJHS5zYwf27oAJFx7xhdnf9cFrWQqN00IujWidXpNY4UfuGqD4NhhRHu4alTbC8Zj6jVZfVwg5JpCwm0VLQr0GUopuqjlN+sw1lxPeDxJuCy5aKHCRthVisH6/e2OgGeGXaUXjaixO/hWINA+PZeOUAODa+SICpXuXKJ53sMNci1uSwkJReL0BsDrw== Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTXPR0101MB0832.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Wed, 23 Sep 2020 01:18:18 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3391.027; Wed, 23 Sep 2020 01:18:18 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Hackers , Konstantin Belousov Subject: Re: RFC: copy_file_range(3) Thread-Topic: RFC: copy_file_range(3) Thread-Index: AQHWj2Uep8NVOqCTP0KuS7h/nlgLPqlxrARqgAAEfICAAHAflYAAMOYAgAMOVBw= Date: Wed, 23 Sep 2020 01:18:18 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 941dd4ec-0874-4e7f-6774-08d85f5e8dd6 x-ms-traffictypediagnostic: YTXPR0101MB0832: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UAoCPl6untVkLNCzki6YSMleTACIqYt2FV68YcKcG04a4eouzrVS1hyq/TlmuFDKqE+Zv9d5sJ0/xAVTm58DD7y1kvIEHX43bLETmrtWosEYxqs+FMXrMZKK3+7AXE3T1lVLX/hVfVqGrvtE00RvPZ3julXyyNdDsa05DF29nNl1I3xDavyI3W7lBbJ+ZdUX8qE8hRjBGN8+h3o3Xp3LNQzxIXwV2+42cpvefHZzw+RmJymbESEk45DahYRIIBN3bVsB6t4WrLas4FIlzWKkoF3ik4jd4qJMRtoDkWXK7xA7dNkczLzVlOBjeo81H8Wo x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(396003)(39850400004)(136003)(366004)(8676002)(66946007)(55016002)(64756008)(316002)(33656002)(786003)(99936003)(478600001)(66446008)(66576008)(71200400001)(66476007)(6916009)(9686003)(54906003)(52536014)(66556008)(8936002)(91956017)(6506007)(450100002)(2906002)(186003)(76116006)(5660300002)(7696005)(4326008)(83380400001)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0O+ougP7w05s4efAmLQxnBp2r/a7X+QJxxf9STZLrT4fUGs37WmEXvOfS7KFTod5lELikfPiUIQGUJR0ZZxnGM/CzC9rv3zf+mt40p5+pAXmEdGyHB2MOrMiveK3X2ywBucoBXZUcmI1jpyHUJF4/OnGFP4atPnh3qxysaGDqs37rTi3exKxDYWVZpBBeoLRJHPfs+1Qks48GsJK9kzI28Kvdrlzm+PoG2jkbP5WXQsT7784RfuBborxCvSINFPZJeJjXlzhOWTj3SngP6lFAsRGS2l6R6zWO3I/YxFKfZRSru6FDQwgsXmUIIKFTSJ680zMHnyW8xxm3E22Orxw08+yzVTmILjLleU4MjjhSqoeYyF/5s1xyMgpBYT5adAMJnm+vzD1FgAPmNs4yHwn3ycRU7zi/znT8V+UNm6EN60qszVSHAaGmm6BiqrXCPbGwJqc6evHQjlS8M/Klruf0YwlqPDTReV2NXcUBc4jBHUfQi22CiRPrsqjYIbzUwN9F79S9Yf1WdLB23asYajg8CxP9XNqsoN6pUK3F9Qcw9VSd9XZMGCxiRV7EzfDWuMbrD+APNHcjgESHFiQ81wo14ixH1esJaF4YOMYHB3myvYSgyqW9QN8yGAD/J4CRcZq/Ur7VOe6uGG4XrBXrEnyndLTHoVzJwXM7Tt0F9wmmKdCEgazXOS1gFgU7OTzK+AGnwtFAfdCA3nn5yhPFRBMbg== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 941dd4ec-0874-4e7f-6774-08d85f5e8dd6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 01:18:18.2669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 58AMYx0CFhjEBz5hVuI3GnHpwbEkbOTHSwEXjuBYb6YTNEK0HzXOuDqHUbn/fQXh27dfrVUcoIFo/qSLHR7JxA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB0832 X-Rspamd-Queue-Id: 4Bx0g03yqhz41yS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=wYzha3am; dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.84 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.63 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.74)[-0.739]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-0.96)[-0.964]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.03)[-1.028]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.84:from]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2020 01:18:21 -0000 --_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alan Somers wrote:=0A= [lots of stuff snipped]=0A= >1) In order to quickly respond to a signal, a program must use a modest le= n with >copy_file_range=0A= For the programs you have mentioned, I think the only signal handling would= =0A= be termination (C or SIGTERM if you prefer).=0A= I'm not sure what is a reasonable response time for this.=0A= I'd like to hear comments from others?=0A= - 1sec, less than 1sec, a few seconds, ...=0A= =0A= > 2) If a hole is larger than len, that will cause vn_generic_copy_file_ran= ge to=0A= > truncate the output file to the middle of the hole. Then, in the next in= vocation, =0A= > truncate it again to a larger size.=0A= > 3) The result is a file that is not as sparse as the original.=0A= Yes. So, the trick is to use the largest "len" you can live with, given how= long you=0A= are willing to wait for signal processing.=0A= =0A= > For example, on UFS:=0A= > $ truncate -s 1g sparsefile=0A= Not a very interesting sparse file. I wrote a little program to create one.= =0A= > $ cp sparsefile sparsefile2=0A= > $ du -sh sparsefile*=0A= > 96K sparsefile=0A= > 32M sparsefile2=0A= >=0A= > My idea for a userland wrapper would solve this problem by using =0A= > SEEK_HOLE/SEEK_DATA to copy holes in their entirety, and use copy_file_ra= nge for=0A= > everything else with a modest len. Alternatively, we could eliminate the= need for=0A= > the wrapper by enabling copy_file_range for every file system, and making= =0A= > vn_generic_copy_file_range interruptible, so copy_file_range can be calle= d with =0A= > large len without penalizing signal handling performance.=0A= =0A= Well, I ran some quick benchmarks using the attached programs, plus "cp" bo= th=0A= before and with your copy_file_range() patch.=0A= copya - Does what I think your plan is above, with a limit of 2Mbytes for "= len".=0A= copyb -Just uses copy_file_range() with 128Mbytes for "len".=0A= =0A= I first created the sparse file with createsparse.c. It is admittedly a wor= st case,=0A= creating alternating holes and data blocks of the minimum size supported by= =0A= the file system. (I ran it on a UFS file system created with defaults, so t= he minimum=0A= hole size is 32Kbytes.)=0A= The file is 1Gbyte in size with an Allocation size of 524576 ("ls -ls").=0A= =0A= I then ran copya, copyb, old-cp and new-cp. For NFS, I redid the mount befo= re=0A= each copy to avoid data caching in the client.=0A= Here's what I got:=0A= Elapsed time #RPCs Allocat= ion size ("ls -ls" on server)=0A= NFSv4.2 =0A= copya 39.7sec 16384copy+32768seek 524576=0A= copyb 10.2sec 104copy 524= 576=0A= old-cp 21.9sec 16384read+16384write 1048864=0A= new-cp 10.5sec 1024copy 5245= 76=0A= =0A= NFSv4.1=0A= copya 21.8sec 16384read+16384write 1048864=0A= copyb 21.0sec 16384read+16384write 1048864=0A= old-cp 21.8sec 16384read+16384write 1048864=0A= new-cp 21.4sec 16384read+16384write 1048864=0A= =0A= Local on the UFS file system=0A= copya 9.2sec n/a = 524576=0A= copyb 8.0sec n/a = 524576=0A= old-cp 15.9sec n/a = 1048864=0A= new-cp 7.9sec n/a = 524576=0A= =0A= So, for a NFSv4.2 mount, using SEEK_DATA/SEEK_HOLE is definitely=0A= a performance hit, due to all the RPC rtts.=0A= Your patched "cp" does fine, although a larger "len" reduces the=0A= RPC count against the server.=0A= All variants using copy_file_range() retain the holes.=0A= =0A= For NFSv4.1, it (not surprisingly) doesn't matter, since only NFSv4.2=0A= supports SEEK_DATA/SEEK_HOLE and VOP_COPY_FILE_RANGE().=0A= =0A= For UFS, everything using copy_file_range() works pretty well and=0A= retains the holes.=0A= Although "copya" is guaranteed to retain the holes, it does run noticably= =0A= slower than the others. Not sure why? Does the extra SEEK_DATA/SEEK_HOLE=0A= syscalls cost that much?=0A= =0A= The limitation of not using SEEK_DATA/SEEK_HOLE is that you will not=0A= retain holes that straddle the byte range copied by two subsequent=0A= copy_file_range(2) calls.=0A= --> This can be minimized by using a large "len", but that large "len"=0A= results in slower response to signal handling.=0A= =0A= I've attached the little programs, so you can play with them.=0A= (Maybe try different sparse schemes/sizes? It might be fun to=0A= make the holes/blocks some random multiple of hole size up=0A= to a limit?)=0A= =0A= rick=0A= ps: In case he isn't reading hackers these days, I've added kib@=0A= as a cc. He might know why UFS is 15% slower when SEEK_HOLE=0A= SEEK_DATA is used.=0A= =0A= =0A= -Alan=0A= --_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_ Content-Type: text/plain; name="copyb.c" Content-Description: copyb.c Content-Disposition: attachment; filename="copyb.c"; size=765; creation-date="Wed, 23 Sep 2020 01:14:16 GMT"; modification-date="Wed, 23 Sep 2020 01:14:16 GMT" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o PgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxzeXMvcGFy YW0uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3N0YXQuaD4KI2luY2x1 ZGUgPGVyci5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CgppbnQKbWFpbihpbnQgYXJnYywgY2hhciAq YXJndltdKQp7CglpbnQgaSwgaW5mZCwgb3V0ZmQ7CglzdHJ1Y3Qgc3RhdCBpbnN0LCBvdXRzdDsK CW9mZl90IHNlZWtkYXRhLCBzZWVraG9sZSwgeGZlciwgb2ZmcG9zOwoJc2l6ZV90IGxlbjsKCXNz aXplX3QgcnNpejsKCWNoYXIgY3A7CgoJaWYgKGFyZ2MgIT0gMykKCQllcnJ4KDEsICJVc2FnZTog Y29weWIgPGluZmlsZT4gPG91dGZpbGU+Iik7CglpbmZkID0gb3Blbihhcmd2WzFdLCBPX1JET05M WSwgMCk7CglpZiAoaW5mZCA8IDApCgkJZXJyKDEsICJjYW4ndCBvcGVuICVzIiwgYXJndlsxXSk7 CglvdXRmZCA9IG9wZW4oYXJndlsyXSwgT19DUkVBVCB8IE9fUkRXUiwgMDY0NCk7CglpZiAob3V0 ZmQgPCAwKQoJCWVycigxLCAiY2FuJ3QgY3JlYXRlICVzIiwgYXJndlsyXSk7CgoJLyogTm93LCBj b3B5IGluZmQgdG8gb3V0ZmQuICovCglkbyB7CgkJc2Vla2RhdGEgPSBjb3B5X2ZpbGVfcmFuZ2Uo aW5mZCwgTlVMTCwgb3V0ZmQsIE5VTEwsCgkJICAgIDEyOCAqIDEwMjQgKiAxMDI0LCAwKTsKCX0g d2hpbGUgKHNlZWtkYXRhID4gMCk7Cn0K --_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_ Content-Type: text/plain; name="createsparse.c" Content-Description: createsparse.c Content-Disposition: attachment; filename="createsparse.c"; size=1139; creation-date="Wed, 23 Sep 2020 01:14:32 GMT"; modification-date="Wed, 23 Sep 2020 01:14:32 GMT" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KI2luY2x1ZGUgPHN0cmluZy5o PgojaW5jbHVkZSA8ZmNudGwuaD4KI2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxzeXMvcGFy YW0uaD4KI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3N0YXQuaD4KI2luY2x1 ZGUgPGVyci5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CgpzdGF0aWMgY2hhciBvdXRidWZbMTAyNCAq IDEwMjRdOwoKaW50Cm1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKewoJaW50IGksIG91dGZk OwoJc3RydWN0IHN0YXQgaW5zdCwgb3V0c3Q7CglvZmZfdCBzZWVrZGF0YSwgc2Vla2hvbGUsIHhm ZXIsIG9mZnBvczsKCXNpemVfdCBsZW47Cglzc2l6ZV90IHJzaXo7CgljaGFyIGNwOwoJbG9uZyBo b2xlc2l6OwoKCWlmIChhcmdjICE9IDIpCgkJZXJyeCgxLCAiVXNhZ2U6IGNyZWF0ZXNwYXJzZSA8 aW5maWxlPiIpOwoJLyogRmlsbCBpbiBpbmJ1ZiB3aXRoIHRoZSBhbHBoYWJldCBvdmVyIGFuZCBv dmVyIGFuZCBvdmVyIGFnYWluLiAqLwoJY3AgPSAnYSc7Cglmb3IgKGkgPSAwOyBpIDwgc2l6ZW9m KG91dGJ1Zik7IGkrKykgewoJCW91dGJ1ZltpXSA9IGNwKys7CgkJaWYgKGNwID4gJ3onKQoJCQlj cCA9ICdhJzsKCX0KCW91dGZkID0gb3Blbihhcmd2WzFdLCBPX0NSRUFUIHwgT19SRFdSLCAwNjQ0 KTsKCWlmIChvdXRmZCA8IDApCgkJZXJyKDEsICJjYW4ndCBvcGVuICVzIiwgYXJndlsxXSk7CgoJ aG9sZXNpeiA9IGZwYXRoY29uZihvdXRmZCwgX1BDX01JTl9IT0xFX1NJWkUpOwoJaWYgKGhvbGVz aXogPD0gMCkKCQllcnIoMSwgIkNhbid0IGdldCBtaW4gaG9sZSBzaXplIik7CgkvKiBDcmVhdGUg dGhlIHNwYXJzZSBmaWxlLiAqLwoJeGZlciA9IDEwMjQgKiAxMDI0ICogMTAyNDsKcHJpbnRmKCJ4 ZmVyPSVqZFxuIiwgKGludG1heF90KXhmZXIpOwoJZm9yIChvZmZwb3MgPSAwOyBvZmZwb3MgPCB4 ZmVyOyBvZmZwb3MgKz0gMiAqIGhvbGVzaXopIHsKcHJpbnRmKCJ4ZmVyPSVqZCBvZmZwb3M9JWpk XG4iLCAoaW50bWF4X3QpeGZlciwgKGludG1heF90KW9mZnBvcyk7CgkJbHNlZWsob3V0ZmQsIGhv bGVzaXosIFNFRUtfQ1VSKTsKCQl3cml0ZShvdXRmZCwgb3V0YnVmLCBob2xlc2l6KTsKCX0KfQo= --_003_YTBPR01MB3966BA18F43F7B6353171E67DD380YTBPR01MB3966CANP_--