Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfvwL-006Crf-2n for pgsql-general@arkaria.postgresql.org; Wed, 14 Jan 2026 08:09:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfvwL-008ooN-0U for pgsql-general@arkaria.postgresql.org; Wed, 14 Jan 2026 08:09:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfvwK-008ooE-1F for pgsql-general@lists.postgresql.org; Wed, 14 Jan 2026 08:09:17 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfvwG-000LPG-0A for pgsql-general@lists.postgresql.org; Wed, 14 Jan 2026 08:09:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1768378149; bh=e4ljEPfVHOi5s08sinnnFq964K4imUfCrfOMsu2vy/g=; h=Message-ID:Date:User-Agent:Subject:To:References:From:In-Reply-To: From; b=l+eb30aWYI9/Jl4U1jKI/RLSSGgWZWClZfTmnIbZRkaZmrWcA+b+5QBF5la3dgWGS SX+Btp8G4ouXdL304VrzlXB5TQmpm8sIyDtzod5jf8KdKzzkYbfQF6oy/QkKoPMwL9 DYJFe74SuBACQDEnLzRFlQlFzirJMDOok4Fers2TwUaWoOZ/5VB3Xr7t6T6/88De6r Z02ttaG4QcMTVDWqcH82cNokBZnM2gbsEVZKavqIm0XCMzqAK2+U94LxjAauWzcJv7 a7UUpwvlu6gE09vTeNplEcO2HWp7ewRRZnsRvK6KV+tnlGymuUofyPFtbHs1wk0EyZ uXxtD3Tnv8Xww== Received: from [172.30.48.66] (debian11-template.l.postgrespro.ru [192.168.2.254]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: a.fedorov@postgrespro.ru) by mail.postgrespro.ru (Postfix/465) with ESMTPSA id 0B34C6077C; Wed, 14 Jan 2026 11:09:09 +0300 (MSK) Content-Type: multipart/mixed; boundary="------------0Rh76R2CiqCY3RecHO0tOxXp" Message-ID: Date: Wed, 14 Jan 2026 12:09:08 +0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Error:could not extend file " with FileFallocate(): No space left on device To: =?UTF-8?B?UGVjc8O2ayBKw6Fu?= , "pgsql-general@lists.postgresql.org" References: Content-Language: en-US From: Aleksandr Fedorov In-Reply-To: X-KSMG-AntiPhishing: NotDetected, bases: 2026/01/14 07:37:00 X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2026/01/14 06:17:00 #28113283 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------0Rh76R2CiqCY3RecHO0tOxXp Content-Type: multipart/alternative; boundary="------------TAThR30x6NuLZzQ9Tk0ngsZ8" --------------TAThR30x6NuLZzQ9Tk0ngsZ8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear community, Based on the analysis of logs collected from several incidents under OEL 8.10 / 9.3, the most likely cause is local exhaustion of free space in an allocation group in the XFS filesystem. Further investigation revealed that a similar issue is documented in the Red Hat knowledge base (https://access.redhat.com/solutions/7129010), describing ENOSPC errors from the fallocate() function in XFS filesystems during PostgreSQL backup operations. Red Hat references the commit https://github.com/torvalds/linux/commit/6773da870ab89123d1b513da63ed59e32a29cb77 and believes that this kernel fix may address the PostgreSQL issue. After analyzing the change set from this commit, we identified the following combination of conditions that can trigger the ENOSPC error: 1. Presence of delayed allocations (committed but not yet written to disk). 2. Insufficient free space in the allocation group to cover all pending delayed allocations. Subsequent search of the PostgreSQL community knowledge base led to the message https://www.postgresql.org/message-id/50A117B6.5030300@optionshouse.com. Important points to highlight from this message: 1. Since kernel versions 2.6.x, XFS has implemented dynamic speculative preallocation. 2. The term "dynamic" means the preallocation size is regulated by internal heuristics. 3. These heuristics are based on file access patterns and history. 4. Additional space allocated during preallocation is intended to prevent file fragmentation. 5. When a file extends, its data is written into extents that may be distributed across one or more allocation groups. 6. Delayed allocation writes allow merging multiple allocations into preallocated space before writing to disk, reducing the number of extents and thus file fragmentation. 7. The logic for tracking additional space retains it as long as there are in-memory references to the file — for example, in an actively running PostgreSQL database. 8. The XFS filesystem itself considers this space as used. 9. The actual file size may exceed the 1GB limit (not to be confused with apparent size). This is confirmed by information collected using the `du -h` command, which shows "actual" file sizes and helps to detect files larger than 1GB at the time of command execution (some even up to 2GB but we know that maximum size is 1GB). There may have been more such files, but after the replica crash, file descriptors were released, causing the "actual" size to return to normal. The dynamic allocator can be disabled by specifying the `allocsize` mount option when mounting the XFS filesystem. We would like to share additional observations to help resolve the issue. We were able to reproduce the original problem in two ways: directly on a PostgreSQL replica, and using a C program. The first method is a test script (please see the attached README_test_pg.md) that uses the mount option `allocsize=$(1*1024*1024)` when mounting the disk where PGDATA is located. The pgbench_accounts table is generated using the pgbench tool, and multiple copies of this table are created and populated in parallel. During the process of filling these small tables (each table is no larger than 25 MB upon script completion), numerous delayed preallocation events occur, consuming free disk space. The subsequent parallel INSERT statements then cause replica crashes because there is no contiguous free space left on the disk to extend the file of the large table. Here an example of availabled free space in mounted points after replica is crashed with ENOSPC error ( pgdata_main is related to primary server and pgdata_repl is related to replica ): Filesystem     Type  Size  Used Avail Use% Mounted on /dev/loop0     xfs   4.0G  4.0G   74M  99% /pgdata_main /dev/loop3     xfs   4.0G  3.8G  280M  94% /pgdata_repl You may observe that when the issue is reproduced and the replica crashes, the available disk space on the replica side appears larger than on the primary side. However, the ENOSPC error in the logs indicates that disk space was exhausted — and this is indeed accurate: after the crash, all file descriptors were released, and the space previously preallocate files was reclaimed by the filesystem. Monitoring of files size using "du -h" right before the moment of crash and some time ago after that is showing that files sizes are decrease from 26 Mb to 25 Mb. The issue does not occur when using the minimum possible value for the allocsize parameter, which is set to allocsize=$(4*1024). Testing various values of allocsize under a specific workload on PostgreSQL with synchronous physical replication shows: +----------------------+----------------------+---------------------------------------------------------------------+ | allocsize setting    | Thread model         | Result                                                   | +----------------------+----------------------+---------------------------------------------------------------------+ | 1M                   | single thread        | No issues observed                                                  | +----------------------+----------------------+---------------------------------------------------------------------+ | 1M                   | multiple threads     | Replica failed: "could not extend file ... No space left on device" | +----------------------+----------------------+---------------------------------------------------------------------+ | 1GB                  | multiple threads     | Primary failed: "could not extend file ... No space left on device" | +----------------------+----------------------+---------------------------------------------------------------------+ | 4KB                  | multiple threads     | No failure occurred                                                 | +----------------------+----------------------+---------------------------------------------------------------------+ Another method is C program ( please find README_test_c.md ) which reproduces the ENOSPC error on kernel version 5.15.0-101.103.2.1.el9uek.x86_64. The program first attempts to write 748 KB to a file and then allocate an additional 16 KB using posix_fallocate(). If posix_fallocate() fails, it displays a corresponding message and retries the operation. The second attempt succeeds, indicating that space was available. However, the program does not fully reproduce the potential PostgreSQL scenario, key differences are: 1. The program uses a single process with a single thread, whereas real systems involve one process with multiple threads or multiple processes operating on files. 2. The program uses a fixed buffer size for the mounted filesystem's journal, whereas in production environments the buffer size is dynamic (allocated based on historical space usage, i.e., workload-dependent). 3. The issue does not occur when there are multiple allocation groups that are completely empty. In our practice, we identified two viable approaches: 1. As a permanent solution: Upgrade the UEK kernel.    Note that the fix has not been backported to all UEK versions:    - It is not present in UEK7 (5.15.x).    - It is present in UEK8 (6.12.x, available starting with OL 9.5) from kernel version 6.12.0-0.20.20 onwards. 2. As a temporary solution: Use the allocsize parameter to disable dynamic speculative preallocation.    However, since this does not fix the root cause, failures may still occur. On 9/10/24 17:11, Pecsök Ján wrote: > > Dear community, > > After upgrade of Posgres from version 13.5 to 16.2 we experience > following error: > > could not extend file > "pg_tblspc/16401/PG_16_202307071/17820/3968302971" with > FileFallocate(): No space left on device > > We cannot easily replicate problem. It happens at randomly every 1-2 > weeks of intensive query computation. > > Was there some changes in space allocation from Posgres 13.5  to > Posgres  16.2? > > Database has  size 91TB and has 27TB more space available. > --------------TAThR30x6NuLZzQ9Tk0ngsZ8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear community,

Based on the analysis of logs collected from several incidents under OEL 8.10 / 9.3, the most likely cause is local exhaustion of free space in an allocation group in the XFS filesystem.

Further investigation revealed that a similar issue is documented in the Red Hat knowledge base (https://access.redhat.com/solutions/7129010), 
describing ENOSPC errors from the fallocate() function in XFS filesystems during PostgreSQL backup operations. 
Red Hat references the commit https://github.com/torvalds/linux/commit/6773da870ab89123d1b513da63ed59e32a29cb77 and 
believes that this kernel fix may address the PostgreSQL issue.

After analyzing the change set from this commit, we identified the following combination of conditions that can trigger the ENOSPC error:
1. Presence of delayed allocations (committed but not yet written to disk).
2. Insufficient free space in the allocation group to cover all pending delayed allocations.

Subsequent search of the PostgreSQL community knowledge base led to the message https://www.postgresql.org/message-id/50A117B6.5030300@optionshouse.com.

Important points to highlight from this message:
1. Since kernel versions 2.6.x, XFS has implemented dynamic speculative preallocation.
2. The term "dynamic" means the preallocation size is regulated by internal heuristics.
3. These heuristics are based on file access patterns and history.
4. Additional space allocated during preallocation is intended to prevent file fragmentation.
5. When a file extends, its data is written into extents that may be distributed across one or more allocation groups.
6. Delayed allocation writes allow merging multiple allocations into preallocated space before writing to disk, reducing the number of extents and thus file fragmentation.
7. The logic for tracking additional space retains it as long as there are in-memory references to the file — for example, in an actively running PostgreSQL database.
8. The XFS filesystem itself considers this space as used.
9. The actual file size may exceed the 1GB limit (not to be confused with apparent size).

This is confirmed by information collected using the `du -h` command, which shows "actual" file sizes and helps to detect files larger than 1GB at the time of command execution (some even up to 2GB but we know that maximum size is 1GB). 
There may have been more such files, but after the replica crash, file descriptors were released, causing the "actual" size to return to normal.

The dynamic allocator can be disabled by specifying the `allocsize` mount option when mounting the XFS filesystem.

We would like to share additional observations to help resolve the issue.

We were able to reproduce the original problem in two ways: directly on a PostgreSQL replica, and using a C program.

The first method is a test script (please see the attached README_test_pg.md) that uses the mount option `allocsize=$(1*1024*1024)` when mounting the disk where PGDATA is located.
The pgbench_accounts table is generated using the pgbench tool, and multiple copies of this table are created and populated in parallel.
During the process of filling these small tables (each table is no larger than 25 MB upon script completion), numerous delayed preallocation events occur, consuming free disk space.
The subsequent parallel INSERT statements then cause replica crashes because there is no contiguous free space left on the disk to extend the file of the large table.

Here an example of availabled free space in mounted points after replica is crashed with ENOSPC error ( pgdata_main is related to primary server and pgdata_repl is related to replica ):
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/loop0     xfs   4.0G  4.0G   74M  99% /pgdata_main
/dev/loop3     xfs   4.0G  3.8G  280M  94% /pgdata_repl

You may observe that when the issue is reproduced and the replica crashes, the available disk space on the replica side appears larger than on the primary side.
However, the ENOSPC error in the logs indicates that disk space was exhausted — and this is indeed accurate: after the crash, all file descriptors were released, and the space previously preallocate files was reclaimed by the filesystem. Monitoring of files size using "du -h" right before the moment of crash and some time ago after that is showing that files sizes are decrease from 26 Mb to 25 Mb. 

The issue does not occur when using the minimum possible value for the allocsize parameter, which is set to allocsize=$(4*1024).
Testing various values of allocsize under a specific workload on PostgreSQL with synchronous physical replication shows:
+----------------------+----------------------+---------------------------------------------------------------------+
| allocsize setting    | Thread model         | Result                                                              |
+----------------------+----------------------+---------------------------------------------------------------------+
| 1M                   | single thread        | No issues observed                                                  |
+----------------------+----------------------+---------------------------------------------------------------------+
| 1M                   | multiple threads     | Replica failed: "could not extend file ... No space left on device" |
+----------------------+----------------------+---------------------------------------------------------------------+
| 1GB                  | multiple threads     | Primary failed: "could not extend file ... No space left on device" |
+----------------------+----------------------+---------------------------------------------------------------------+
| 4KB                  | multiple threads     | No failure occurred                                                 |
+----------------------+----------------------+---------------------------------------------------------------------+

Another method is C program ( please find README_test_c.md ) which reproduces the ENOSPC error on kernel version 5.15.0-101.103.2.1.el9uek.x86_64.
The program first attempts to write 748 KB to a file and then allocate an additional 16 KB using posix_fallocate(). 
If posix_fallocate() fails, it displays a corresponding message and retries the operation. 
The second attempt succeeds, indicating that space was available.

However, the program does not fully reproduce the potential PostgreSQL scenario, key differences are:
1. The program uses a single process with a single thread, whereas real systems involve one process with multiple threads or multiple processes operating on files.
2. The program uses a fixed buffer size for the mounted filesystem's journal, whereas in production environments the buffer size is dynamic (allocated based on historical space usage, i.e., workload-dependent).
3. The issue does not occur when there are multiple allocation groups that are completely empty.

In our practice, we identified two viable approaches:

1. As a permanent solution: Upgrade the UEK kernel.
   Note that the fix has not been backported to all UEK versions:
   - It is not present in UEK7 (5.15.x).
   - It is present in UEK8 (6.12.x, available starting with OL 9.5) from kernel version 6.12.0-0.20.20 onwards.
2. As a temporary solution: Use the allocsize parameter to disable dynamic speculative preallocation.
   However, since this does not fix the root cause, failures may still occur.

On 9/10/24 17:11, Pecsök Ján wrote:

Dear community,

 

After upgrade of Posgres from version 13.5 to 16.2 we experience following error:

could not extend file "pg_tblspc/16401/PG_16_202307071/17820/3968302971" with FileFallocate(): No space left on device

 

We cannot easily replicate problem. It happens at randomly every 1-2 weeks of intensive query computation.

Was there some changes in space allocation from Posgres 13.5  to Posgres  16.2?

 

Database has  size 91TB and has 27TB more space available.

 

--------------TAThR30x6NuLZzQ9Tk0ngsZ8-- --------------0Rh76R2CiqCY3RecHO0tOxXp Content-Type: text/markdown; charset=UTF-8; name="README_test_pg.md" Content-Disposition: attachment; filename="README_test_pg.md" Content-Transfer-Encoding: base64 IyBSZXByb2R1Y2luZyBFTk9TUEMgRXJyb3IgaW4gUG9zdGdyZVNRTAoKVGhpcyBzY3JpcHQg cmVwcm9kdWNlcyBhbiBgRU5PU1BDYCAoRXJyb3I6IE5vIFNwYWNlIExlZnQgb24gRGV2aWNl KSBjb25kaXRpb24gaW4gUG9zdGdyZVNRTCBieSBleHBsb2l0aW5nIGZpbGVzeXN0ZW0tbGV2 ZWwgZXh0ZW50IGFsbG9jYXRpb24gYmVoYXZpb3IgdW5kZXIgaGlnaC1jb25jdXJyZW5jeSB3 b3JrbG9hZHMuIFRoZSBpc3N1ZSBpcyB0cmlnZ2VyZWQgYnkgYSBjb21iaW5hdGlvbiBvZjoK CiogICBNb3VudCBvcHRpb24gYGFsbG9jc2l6ZT0xTWAgb24gdGhlIGAkUEdEQVRBYCBtb3Vu dCBwb2ludAoqICAgQ3JlYXRpb24gb2YgbWFueSBzbWFsbCB0YWJsZXMgKHByZWFsbG9jYXRp bmcgZmlsZXN5c3RlbSBleHRlbnRzKQoqICAgUGFyYWxsZWwgYnVsayBpbnNlcnRzIGludG8g YSBzaW5nbGUgbGFyZ2UgdGFibGUgKGZyYWdtZW50aW5nIGZyZWUgc3BhY2UpCgpUaGlzIG1p bWljcyByZWFsLXdvcmxkIHNjZW5hcmlvcyBzdWNoIGFzIGRhdGEgbWlncmF0aW9uIG9yIGJ1 bGsgRVRMIG9wZXJhdGlvbnMsIHdoZXJlIGZpbGVzeXN0ZW0gZnJhZ21lbnRhdGlvbiBsZWFk cyB0byBhbGxvY2F0aW9uIGZhaWx1cmVzIGV2ZW4gd2hlbiB0b3RhbCBmcmVlIHNwYWNlIGFw cGVhcnMgc3VmZmljaWVudC4KCi0tLQoKIyMgUHJlcmVxdWlzaXRlcwoKKiAgIFBvc3RncmVT UUwgMTYuMSB3aXRoIGBwZ2JlbmNoYCBpbnN0YWxsZWQKKiAgICoqWEZTKiogZmlsZXN5c3Rl bSAocmVjb21tZW5kZWQpCiogICBgJFBHREFUQWAgYW5kIFdBTCBsb2dzIGxvY2F0ZWQgb24g ZGlmZmVyZW50IG1vdW50IHBvaW50cwoqICAgTW91bnQgb3B0aW9uOiBgYWxsb2NzaXplPTFN YCAob3IgaGlnaGVyKSBvbiB0aGUgYCRQR0RBVEFgIG1vdW50IHBvaW50ICAKICAgICooVGhp cyBmb3JjZXMgbGFyZ2VyIHByZWFsbG9jYXRpb24gdW5pdHMsIGluY3JlYXNpbmcgZnJhZ21l bnRhdGlvbiByaXNrKSoKKiAgIFN1ZmZpY2llbnQgZGlzayBzcGFjZSAo4omlIDUwIEdCIHJl Y29tbWVuZGVkKQoqICAgTGludXggZW52aXJvbm1lbnQgd2l0aCBgcHNxbGAsIGBwZ2JlbmNo YCwgYHhhcmdzYCwgYW5kIGBzZXFgCgotLS0KCiMjIEtleSBGYWN0b3JzIGZvciBSZXByb2R1 Y3Rpb24KCnwgRmFjdG9yICAgICAgICAgICAgICAgICAgICB8IFJlY29tbWVuZGVkIFZhbHVl ICAgfCBQdXJwb3NlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAp8IDotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gfCA6LS0tLS0t LS0tLS0tLS0tLS0tIHwgOi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIHwKfCBgYWxsb2NzaXplYCBtb3VudCBvcHRpb24g IHwgMU0gICAgICAgICAgICAgICAgICB8IEZvcmNlcyBsYXJnZSBwcmVhbGxvY2F0aW9ucywg aW5jcmVhc2luZyBmcmFnbWVudGF0aW9uIHJpc2sgICAgICB8CnwgTnVtYmVyIG9mIHNtYWxs IHRhYmxlcyAgICB8IDEwMOKAkzIwMCAgICAgICAgICAgICB8IENvbnN1bWVzIGFsbG9jYXRp b24gZ3JvdXBzL2NsdXN0ZXJzICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CnwgUGFy YWxsZWwgdGhyZWFkcyAgICAgICAgICB8IDUw4oCTMTUwICAgICAgICAgICAgICB8IEluY3Jl YXNlcyBjb25jdXJyZW5jeSBhbmQgYWxsb2NhdGlvbiBjb250ZW50aW9uICAgICAgICAgICAg ICAgICB8CnwgVG90YWwgcm93cyBpbnNlcnRlZCAgICAgICB8IDVN4oCTMTBNICAgICAgICAg ICAgICB8IFB1c2hlcyBpbnNlcnQgc2l6ZSBiZXlvbmQgYXZhaWxhYmxlIGNvbnRpZ3VvdXMg ZXh0ZW50cyAgICAgICAgICB8CnwgRmlsZXN5c3RlbSAgICAgICAgICAgICAgICB8IFhGUyAg ICAgICAgICAgICAgICAgfCBFeGhpYml0cyB0aGlzIGJlaGF2aW9yIHVuZGVyIGhpZ2ggZnJh Z21lbnRhdGlvbiAgICAgICAgICAgICAgICAgfAoKLS0tCgojIyBFbnZpcm9ubWVudCBTZXR1 cAoKU2V0IHVwIFhGUyBmaWxlc3lzdGVtcyBvbiBzZXBhcmF0ZSBkaXNrcyBmb3IgUEdEQVRB IGFuZCBQR1dBTCB3aXRoIGFwcHJvcHJpYXRlIG1vdW50IG9wdGlvbnM6CgpgYGBiYXNoCiMg Rm9ybWF0IFBHREFUQSBkaXNrIHdpdGggc2VwYXJhdGUgam91cm5hbCBkZXZpY2UgYW5kIDEy OCBhbGxvY2F0aW9uIGdyb3Vwcwpta2ZzLnhmcyAtZiAtZCBhZ2NvdW50PTEyOCAtbCBsb2dk ZXY9L2Rldi9qb3VybmFsX2Rpc2ssc2l6ZT02NG0gL2Rldi9wZ2RhdGFfZGlzawoKIyBGb3Jt YXQgUEdXQUwgZGlzawpta2ZzLnhmcyAtZiAtZCBhZ2NvdW50PTE2IC9kZXYvcGd3YWxfZGlz awoKIyBDcmVhdGUgbW91bnQgcG9pbnRzCm1rZGlyIC9wZ2RhdGEKbWtkaXIgL3Bnd2FsCgoj IE1vdW50IFBHREFUQSB3aXRoIGFsbG9jc2l6ZT0xTQptb3VudCAtdCB4ZnMgLW8gbG9nZGV2 PS9kZXYvam91cm5hbF9kaXNrLGFsbG9jc2l6ZT0xMDQ4NTc2IC9kZXYvcGdkYXRhX2Rpc2sg L3BnZGF0YQoKIyBNb3VudCBQR1dBTAptb3VudCAtdCB4ZnMgL2Rldi9wZ3dhbF9kaXNrIC9w Z3dhbApgYGAKCkltcG9ydGFudCBjb25maWd1cmF0aW9uIGRldGFpbHM6CgoqIFBHREFUQSBm aWxlc3lzdGVtOiBYRlMgd2l0aCBzZXBhcmF0ZSBqb3VybmFsIGRldmljZSwgbW91bnRlZCB3 aXRoIGFsbG9jc2l6ZT0xTSBvcHRpb24KKiBBbGxvY2F0aW9uIGdyb3VwczogMTI4IEFHcyBm b3IgUEdEQVRBIHRvIGluY3JlYXNlIGZyYWdtZW50YXRpb24gcG90ZW50aWFsCiogU2VwYXJh dGUgbW91bnQ6IFBHV0FMIG9uIGRpZmZlcmVudCBkaXNrL2ZpbGVzeXN0ZW0gdG8gaXNvbGF0 ZSBXQUwgaW1wYWN0CiogRGlzayBzaXppbmc6IFBHREFUQSBkaXNrIHNob3VsZCBoYXZlIHN1 ZmZpY2llbnQgc3BhY2UgKOKJpSA1MEdCIHJlY29tbWVuZGVkKQoqIEZvciBQb3N0Z3JlU1FM IGNvbmZpZ3VyYXRpb24sIGVuc3VyZSBkYXRhX2RpcmVjdG9yeSBwb2ludHMgdG8gL3BnZGF0 YSBhbmQgY29uc2lkZXIgc2V0dGluZyBXQUwgZGlyZWN0b3J5IHRvIC9wZ3dhbC4KCi0tLQoK IyMgUmVwcm9kdWN0aW9uIFNjcmlwdAoKVGhlIGZvbGxvd2luZyBiYXNoIHNjcmlwdCByZXBy b2R1Y2VzIHRoZSBFTk9TUEMgZXJyb3IuCgpgYGBiYXNoCiMgU3RlcCAxOiBjcmVhdGUgaW5p dGlhbCB0YWJsZSB3aGljaCB3aWxsIGJlIHVzZWQgZm9yIGNvcHlpbmcgcm93cwplY2hvICJw cmVwYXJpbmcgZGF0YS4uIgpwZ2JlbmNoIC1VIHBvc3RncmVzIC1oIGxvY2FsaG9zdCAtcCA1 NDMyIC1pIC1JIHQgcG9zdGdyZXMKCiMgU3RlcCAyOiBJbnNlcnQgYmFzZWxpbmUgZGF0YQpw c3FsIC1VIHBvc3RncmVzIC1oIGxvY2FsaG9zdCAtcCA1NDMyIC1jICJJTlNFUlQgSU5UTyBw Z2JlbmNoX2FjY291bnRzKGFpZCxiaWQsYWJhbGFuY2UsZmlsbGVyKSBTRUxFQ1QgZ3MuaSBB UyBhaWQsTlVMTCwwLHN1YnN0cmluZyhtZDUocmFuZG9tKCk6OnRleHQpLDAsODQpIGZyb20g Z2VuZXJhdGVfc2VyaWVzKDEsIDIwMDAwMCkgZ3MoaSkiCgojIFN0ZXAgMzogY3JlYXRlIDEy OCBzbWFsbCB0YWJsZXMgaW4gcGFyYWxsZWwgKHByZWFsbG9jYXRlcyBleHRlbnRzIGFjcm9z cyBBR3MpCmZvciBpIGluICQoc2VxIDEgMTI4KTsgZG8gZWNobyAkaTsgZG9uZSB8IHhhcmdz IC1yIC1QIDEyIC1JICQkIHBzcWwgLVUgcG9zdGdyZXMgLWggbG9jYWxob3N0IC1wIDU0MzIg LWMgImNyZWF0ZSB0YWJsZSBwZ2JlbmNoX2FjY291bnRzJCQgYXMgc2VsZWN0ICogZnJvbSBw Z2JlbmNoX2FjY291bnRzIiA+IC9kZXYvbnVsbAoKIyBTdGVwIDQ6IGNsZWFuIHVwIGluaXRp YWwgc2NoZW1hCnBnYmVuY2ggLVUgcG9zdGdyZXMgLWggbG9jYWxob3N0IC1wIDU0MzIgLWkg LUkgZCBwb3N0Z3JlcwoKIyBTdGVwIDUKZWNobyAicmVwcm9kdWNpbmcuLiIKZXhwb3J0IFRI UkVBRFM9MTAwCmV4cG9ydCBQQVJUUz0xMDAKZXhwb3J0IFRPVEFMPTYwMDAwMDAKZXhwb3J0 IFJBTkdFPSQoKFRPVEFML1BBUlRTKSkKCiMgU3RlcCA2OiBpbnNlcnQgNk0gcm93cyBpbiAx MDAgcGFyYWxsZWwgYmF0Y2hlcyBpbnRvIHBnYmVuY2hfYWNjb3VudHMxCmZvciBpIGluICQo c2VxIDEgJFBBUlRTKTsgZG8gZWNobyAkaTsgZG9uZSB8IHhhcmdzIC1yIC1QICRUSFJFQURT IC1JICQkIHBzcWwgLVUgcG9zdGdyZXMgLWggbG9jYWxob3N0IC1wIDU0MzIgLWMgIklOU0VS VCBJTlRPIHBnYmVuY2hfYWNjb3VudHMxKGFpZCxiaWQsYWJhbGFuY2UsZmlsbGVyKSBTRUxF Q1QgKCQkKiRSQU5HRSk6OmludGVnZXIrZ3MuaSBBUyBhaWQsTlVMTCwwLHN1YnN0cmluZyht ZDUocmFuZG9tKCk6OnRleHQpLDAsODQpIGZyb20gZ2VuZXJhdGVfc2VyaWVzKDEsICRSQU5H RSkgZ3MoaSkiID4gL2Rldi9udWxsCgojIFN0ZXAgNzogZmluYWwgaW5zZXJ0IHRvIHB1c2gg cGFzdCB0aHJlc2hvbGQKcHNxbCAtVSBwb3N0Z3JlcyAtaCBsb2NhbGhvc3QgLXAgNTQzMiAt YyAiSU5TRVJUIElOVE8gcGdiZW5jaF9hY2NvdW50czEoYWlkLGJpZCxhYmFsYW5jZSxmaWxs ZXIpIFNFTEVDVCBncy5pIEFTIGFpZCxOVUxMLDAsc3Vic3RyaW5nKG1kNShyYW5kb20oKTo6 dGV4dCksMCw4NCkgZnJvbSBnZW5lcmF0ZV9zZXJpZXMoMSwgMjAwMDAwKSBncyhpKSIgPiAv ZGV2L251bGwKYGBgCgotLS0KCiMjIEltcG9ydGFudCBOb3RlcwoxLiBTdGVwMyBsZWFkcyB0 byBjcmVhdGlvbiBvZiAxMjggdGFibGVzLCB0aGlzIGNvbnN1bWVzIG1hbnkgYWxsb2NhdGlv biBncm91cHMgKEFHcykgb24gWEZTIGFuZCBwcm9kdWNlcyBhIGxvdCBvZiBkZWxheWVkIHBy ZWFsbG9jYXRpb24gZXZlbnRzLgoyLiBTdGVwNiBjYXVzZXMgcmVhbCBpc3N1ZSB3aXRoIG1l c3NhZ2UgIkZBVEFMOiBjb3VsZCBub3QgZXh0ZW5kIGZpbGUgImJhc2UveHh4eHgveHh4eHh4 eHh4Lnh4eHh4IiB3aXRoIEZpbGVGYWxsb2NhdGUoKTogTm8gc3BhY2UgbGVmdCBvbiBkZXZp Y2UiIGR1ZSB0byBwcmlvciBmcmFnbWVudGF0aW9uIGZyb20gc21hbGwgdGFibGVzLCB0aGUg ZmlsZXN5c3RlbSBjYW5ub3QgZmluZCBhIGxhcmdlIGVub3VnaCBjb250aWd1b3VzIGZyZWUg cmVnaW9uIOKAlCBldmVuIGlmIHRvdGFsIGZyZWUgc3BhY2UgaXMgaGlnaCAoIGJ1dCBub3Qg YXZhaWxhYmxlIGR1ZSB0byBrZWVwaW5nIGJ5IG9wZW5lZCBmaWxlcyBkZXNjcmlwdG9ycyAp CjMuIFN0ZXA3IHNob3VsZCBjb21wbGV0ZSBzdWNjZXNzZnVsbHkgaWYgdGhlIEVOT1NQQyBp c3N1ZSBkaWQgTk9UIG9jY3VyLCBzbyB0aGF0IGlzIHByb292aW5nIHRoYXQgc3BhY2UgaXMg ZW5vdWdoIGZvciBsYXN0IHN0ZXAuCjQuIEFmdGVyIGEgY3Jhc2ggb3IgcmVzdGFydCwgc3Bh Y2UgaXMgcmVjbGFpbWVkIGFzIGZpbGUgZGVzY3JpcHRvcnMgYXJlIHJlbGVhc2VkLiBUaGlz IG1ha2VzIHRoZSBpc3N1ZSBhcHBlYXIgaW50ZXJtaXR0ZW50IOKAlCBidXQgdGhlIHJvb3Qg Y2F1c2UgaXMgZmlsZXN5c3RlbSBmcmFnbWVudGF0aW9uIGR1ZSB0byBzcGVjdWxhdGl2ZSBw cmVhbGxvY2F0aW9uLCBub3QgYWN0dWFsIGRpc2sgZXhoYXVzdGlvbi4K --------------0Rh76R2CiqCY3RecHO0tOxXp Content-Type: text/markdown; charset=UTF-8; name="=?UTF-8?B?UkVBRE1FX3Rlc3Rf0YEubWQ=?=" Content-Disposition: attachment; filename*=UTF-8''%52%45%41%44%4D%45%5F%74%65%73%74%5F%D1%81%2E%6D%64 Content-Transfer-Encoding: base64 IyBSZXByb2R1Y2luZyBFTk9TUEMgRXJyb3IgaW4gQyBQcm9ncmFtCgpUaGlzIEMgcHJvZ3Jh bSByZXByb2R1Y2VzIGFuIGBFTk9TUENgIChFcnJvcjogTm8gU3BhY2UgTGVmdCBvbiBEZXZp Y2UpIGNvbmRpdGlvbiBieSBkZW1vbnN0cmF0aW5nIGhvdyBmaWxlc3lzdGVtIGZyYWdtZW50 YXRpb24gY2FuIGNhdXNlIGFsbG9jYXRpb24gZmFpbHVyZXMgZXZlbiB3aGVuIHN1ZmZpY2ll bnQgZnJlZSBzcGFjZSBleGlzdHMuIFRoZSBpc3N1ZSBvY2N1cnMgd2hlbjoKCiogICBGaWxl c3lzdGVtIGlzIG1vdW50ZWQgd2l0aCBgYWxsb2NzaXplPTFNYAoqICAgTWFueSBzbWFsbCBm aWxlcyBwcmVhbGxvY2F0ZSBzcGFjZSBhY3Jvc3MgYWxsb2NhdGlvbiBncm91cHMKKiAgIEEg bGFyZ2UgZmlsZSBpcyBleHRlbmRlZCwgZm9sbG93ZWQgYnkgYSBzbWFsbCBleHRlbnNpb24g YXR0ZW1wdAoKVGhlIHByb2dyYW0gc2hvd3MgdGhhdCB3aGlsZSB0aGUgaW5pdGlhbCBsYXJn ZSB3cml0ZSBzdWNjZWVkcywgYSBzdWJzZXF1ZW50IHNtYWxsIGBwb3NpeF9mYWxsb2NhdGUo KWAgY2FsbCBmYWlscyB3aXRoIEVOT1NQQyBvbiB0aGUgZmlyc3QgYXR0ZW1wdCBidXQgc3Vj Y2VlZHMgb24gcmV0cnksIHByb3ZpbmcgdGhhdCBmcmVlIHNwYWNlIGV4aXN0cyBidXQgaXNu J3QgY29udGlndW91cy4KCi0tLQoKIyMgUHJlcmVxdWlzaXRlcwoKKiAgIEZpbGVzeXN0ZW06 ICoqWEZTKiogd2l0aCBzZXBhcmF0ZSBkaXNrIGZvciBqb3VybmFsCiogICBNb3VudCBvcHRp b246IGBhbGxvY3NpemU9MU1gIG9uIHRoZSB0YXJnZXQgbW91bnQgcG9pbnQKKiAgIFN1ZmZp Y2llbnQgZGlzayBzcGFjZSAo4omlIDUgR0IgcmVjb21tZW5kZWQpCiogICBTaW5nbGUtdGhy ZWFkZWQgZXhlY3V0aW9uCiogICBMaW51eCBlbnZpcm9ubWVudCB3aXRoIFhGUyBkZXZlbG9w bWVudCB0b29scwoqICAgQyBjb21waWxlciAoZ2NjL2NsYW5nKQoKLS0tCgojIyBLZXkgRmFj dG9ycyBmb3IgUmVwcm9kdWN0aW9uCgp8IEZhY3RvciAgICAgICAgICAgICAgICAgICAgfCBS ZWNvbW1lbmRlZCB2YWx1ZSB8IFB1cnBvc2UgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKfCA6LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tIHwgOi0tLS0tLS0tLS0tLS0tLS0gfCA6LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSB8 CnwgYGFsbG9jc2l6ZWAgbW91bnQgb3B0aW9uICB8IDFNICAgICAgICAgICAgICAgIHwgRm9y Y2VzIDFNQiBwcmVhbGxvY2F0aW9uIHVuaXRzLCBpbmNyZWFzaW5nIGZyYWdtZW50YXRpb24g cmlzayAgICAgICAgICAgfAp8IHNtYWxsIGZpbGVzICgzMU1CIGVhY2gpICAgfCAxMjggICAg ICAgICAgICAgICB8IENvbnN1bWVzIGFsbG9jYXRpb24gZ3JvdXBzLCBmcmFnbWVudGluZyBm cmVlIHNwYWNlICAgICAgICAgICAgICAgICAgICAgIHwKfCBMYXJnZSBpbml0aWFsIHdyaXRl ICAgICAgIHwgNzQ4S0IgICAgICAgICAgICAgfCBDcmVhdGVzIHN1YnN0YW50aWFsIGZpbGUg Z3Jvd3RoIHdpdGhpbiBmcmFnbWVudGVkIHNwYWNlICAgICAgICAgICAgICAgICB8CnwgU21h bGwgZmFsbG9jYXRlIGF0dGVtcHQgICB8IDE2S0IgICAgICAgICAgICAgIHwgVGVzdHMgYWxs b2NhdGlvbiBvZiBzbWFsbCBjb250aWd1b3VzIHNwYWNlIGluIGZyYWdtZW50ZWQgZW52aXJv bm1lbnQgICAgfAp8IEltbWVkaWF0ZSByZXRyeSAgICAgICAgICAgfCBvbiBmYWlsdXJlICAg ICAgICB8IERlbW9uc3RyYXRlcyBzcGFjZSBleGlzdHMgYnV0IHdhc24ndCBjb250aWd1b3Vz IG9uIGZpcnN0IGF0dGVtcHQgICAgICAgIHwKCi0tLQoKIyMgRW52aXJvbm1lbnQgU2V0dXAK CkNyZWF0ZSBhbiBYRlMgZmlsZXN5c3RlbSB3aXRoIHNlcGFyYXRlIGpvdXJuYWwgZGV2aWNl IGFuZCBtb3VudCB3aXRoIGBhbGxvY3NpemU9MU1gOgoKYGBgYmFzaAojIEZvcm1hdCBkaXNr IChyZXBsYWNlIC9kZXYvc2RYIHdpdGggeW91ciBkYXRhIGRpc2ssIC9kZXYvc2RZIHdpdGgg am91cm5hbCBkaXNrKQpta2ZzLnhmcyAtZiAtZCBhZ2NvdW50PTEyOCAtbCBsb2dkZXY9L2Rl di9zZFksc2l6ZT02NG0gL2Rldi9zZFgKCiMgTW91bnQgd2l0aCBhbGxvY3NpemU9MU0KbWtk aXIgL21udC90ZXN0Cm1vdW50IC10IHhmcyAtbyBsb2dkZXY9L2Rldi9zZFksYWxsb2NzaXpl PTEwNDg1NzYgL2Rldi9zZFggL21udC90ZXN0CmBgYAoKLS0tCgojIyBQcmVwYXJpbmcgQyBw cm9ncmFtCmBgYGJhc2gKY2F0ID4gdGVzdC5jIDw8ICdFT0YnCiNpbmNsdWRlIDxmY250bC5o PgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8ZXJy bm8uaD4KI2luY2x1ZGUgPHN0cmluZy5oPgoKaW50IG1haW4oaW50IGFyZ2MsIGNoYXIqIGFy Z3ZbXSkgewoJY29uc3QgY2hhciAqYmFzZWRpciA9ICJtbnQiOwoJY2hhciBmaWxlbmFtZVsy NTZdOwoJY2hhciB3cml0ZWJ1ZlsxMDI0XTsKCWludCBpbmMxID0gNzQ4OwoJaW50IGluYzIg PSAxNjsKCglzcHJpbnRmKGZpbGVuYW1lLCAiJXMvJTAzaS5kYXQiLCBiYXNlZGlyLCAxKTsK CW1lbXNldCh3cml0ZWJ1ZiwgMSwgMTAyNCk7CgoJcHJpbnRmKCJPcGVuaW5nIGZpbGUgJXNc biIsIGZpbGVuYW1lKTsKCWludCBmZCA9IG9wZW4oZmlsZW5hbWUsIE9fUkRXUik7CglpZiAo ZmQgPT0gLTEpIHsKCQlwcmludGYoIkVycm9yIG9uIG9wZW4gZmlsZSAlcyAoY29kZT0laSlc biIsIGZpbGVuYW1lLCBlcnJubyk7CgkJcmV0dXJuIDE7Cgl9CglvZmZfdCBmcyA9IGxzZWVr KGZkLCAwLCBTRUVLX0VORCk7CglwcmludGYoIkN1cnJlbnQgZmlsZSBzaXplOiAlbGlcbiIs IGZzKTsKCQoJcHJpbnRmKCJXcml0aW5nICVpIGJ5dGVzIGF0IHRoZSBmaWxlIGVuZFxuIiwg aW5jMSAqIDEwMjQpOwoJZm9yIChpbnQgaSA9IDA7IGkgPCBpbmMxOyBpKyspIHsKCQlpbnQg d3JpdGVfcmVzdWx0ID0gd3JpdGUoZmQsIHdyaXRlYnVmLCAxMDI0KTsKCQlpZiAod3JpdGVf cmVzdWx0ID09IC0xKSB7CgkJCXByaW50ZigiRXJyb3Igb24gd3JpdGUgKGNvZGU9JWkpXG4i LCBlcnJubyk7CgkJCWNsb3NlKGZkKTsKCQkJcmV0dXJuIDE7CgkJfQoJfQoKCS8qIFRlc3Qg Ki8KCWludCBpdGVyYXRpb24gPSAxOwoJaW50IHRlc3RfcmVzdWx0ID0gMDsKCWRvIHsKCQlw cmludGYoIkFsbG9jYXRlIGFkZHRpb25hbCAlaSBieXRlcyBhdCB0aGUgZmlsZSBlbmRcbiIs IGluYzIgKiAxMDI0KTsKCQl0ZXN0X3Jlc3VsdCA9IHBvc2l4X2ZhbGxvY2F0ZShmZCwgZnMg KyBpbmMxICogMTAyNCwgIGluYzIgKiAxMDI0KTsKCQlpZiAodGVzdF9yZXN1bHQgIT0gMCkg ewoJCQlpZiAodGVzdF9yZXN1bHQgPT0gRU5PU1BDKSB7CgkJCQlwcmludGYoIkVycm9yIEVO T1NQQyBvbiBwb3NpeF9mYWxsb2NhdGUhXG4iKTsKCQkJCWlmIChpdGVyYXRpb24rKyA8IDIp IHsKCQkJCQlwcmludGYoIlJldHJ5aW5nIG9wZXJhdGlvbi4uLlxuIik7CgkJCQkJY29udGlu dWU7CgkJCQl9CgkJCX0KCQkJZWxzZQoJCQkJcHJpbnRmKCJFcnJvciBvbiBwb3NpeF9mYWxs b2NhdGUgKGNvZGU9JWkpXG4iLCB0ZXN0X3Jlc3VsdCk7CgkJCWNsb3NlKGZkKTsKCQkJcmV0 dXJuIDE7CgkJfQoJfSB3aGlsZSAoIHRlc3RfcmVzdWx0ICE9IDAgKTsKCXByaW50ZigiRG9u ZVxuIik7CgljbG9zZShmZCk7CglyZXR1cm4gMDsKfQpFT0YKZWNobyAiQ29tcGlsZSB0ZXN0 IHRvb2wiCmdjYyAtbyB0ZXN0IHRlc3QuYwpgYGAKCi0tLQoKCiMjIFByZXBhcmluZyBkYXRh CmBgYGJhc2gKIyBDcmVhdGUgMTI4IGZpbGVzLCBlYWNoIHByZWFsbG9jYXRpbmcgMzFNQgpm b3IgaSBpbiB7MDAwLi4xMjd9OyBkbwogICAgZmFsbG9jYXRlIC14IC1sIDMxTSAiL21udC90 ZXN0LyR7aX0uZGF0Igpkb25lCmBgYAoKLS0tCgoKIyMgUmVwcm9kdWNpbmcgYnkgQyBQcm9n cmFtCmBgYGJhc2gKdGVzdAojIG91dHB1dDoKI1dyaXRpbmcgNzY1OTUyIGJ5dGVzIGF0IHRo ZSBmaWxlIGVuZAojQWxsb2NhdGUgYWRkaXRpb25hbCAxNjM4NCBieXRlcyBhdCB0aGUgZmls ZSBlbmQKI0Vycm9yIEVOT1NQQyBvbiBwb3NpeF9mYWxsb2NhdGUhCiNSZXRyeWluZyBvcGVy YXRpb24uLi4KI0FsbG9jYXRlIGFkZGl0aW9uYWwgMTYzODQgYnl0ZXMgYXQgdGhlIGZpbGUg ZW5kCiNEb25lCmBgYAoKLS0tCgoKIyMgSW1wb3J0YW50IE5vdGVzCjEuIEVOT1NQQyBpcyBp bnRlcm1pdHRlbnQ6IFRoZSBmaXJzdCBwb3NpeF9mYWxsb2NhdGUoKSBjYWxsIGZhaWxzIHdp dGggRU5PU1BDLCBidXQgdGhlIGlkZW50aWNhbCByZXRyeSBzdWNjZWVkcyBpbW1lZGlhdGVs eS4gVGhpcyBwcm92ZXMgZnJlZSBzcGFjZSBleGlzdHMgYnV0IHdhc24ndCBjb250aWd1b3Vz IG9uIHRoZSBmaXJzdCBhdHRlbXB0LgoyLiBSb290IGNhdXNlOiBGaWxlc3lzdGVtIGZyYWdt ZW50YXRpb24gY2F1c2VkIGJ5OgoqIGFsbG9jc2l6ZT0xTSBmb3JjaW5nIGxhcmdlIHByZWFs bG9jYXRpb24gdW5pdHMKKiAxMjggc21hbGwgZmlsZXMgY29uc3VtaW5nIGFsbG9jYXRpb24g Z3JvdXBzCiogTGFyZ2UgZmlsZSBleHRlbnNpb24gKDc0OEtCKSBmcmFnbWVudGluZyByZW1h aW5pbmcgc3BhY2UKMy4gTm90IGEgZGlzayBzcGFjZSBpc3N1ZTogVGhlIHJldHJ5IHN1Y2Nl c3MgZGVtb25zdHJhdGVzIHN1ZmZpY2llbnQgZnJlZSBzcGFjZSBleGlzdHMuIFRoZSBmYWls dXJlIGlzIGR1ZSB0byBpbmFiaWxpdHkgdG8gZmluZCBjb250aWd1b3VzIHNwYWNlIGZvciB0 aGUgc21hbGwgKDE2S0IpIGFsbG9jYXRpb24uCg== --------------0Rh76R2CiqCY3RecHO0tOxXp--