测试S3A文件系统客户端及其功能

任何补丁的提交者都需要运行所有集成测试，并声明他们使用的S3区域/实现。

重要提示：未包含此声明的补丁将被忽略

该策略已被证明是保证代码变更完全回归测试的唯一机制。为什么需要声明区域？有两个原因

1. 它帮助我们识别仅针对特定端点或S3协议的第三方实现才会出现的回归问题。
2. 它迫使提交者在测试方面更加诚实。很容易撒谎说"是的，我测试过这个"，但要说"是的，我在S3 US-west上测试过这个"就是更具体的谎言，更难编造。而且，如果被发现：你在项目中将失去所有信誉。

你不需要在AWS基础设施内的虚拟机中进行测试；使用-Dparallel-tests选项时，非规模测试可在二十分钟内完成。由于测试完成后会自动清理，这些测试也被设计为低成本。运行测试既不困难也不昂贵；如果你无法运行测试，就无法保证你的补丁有效。评审人员已经有足够多的工作要做，没有时间进行这些测试，尤其是每次失败都会导致开发迭代变慢的情况下。

Please: run the tests. And if you don’t, we are sorry for declining your patch, but we have to.

如果测试出现间歇性故障怎么办？

某些测试会间歇性失败，特别是在并行运行时。如果发生这种情况，可以尝试单独运行该测试以查看是否成功。

如果仍然失败，请在您的声明中包含这一事实。我们知道某些测试偶尔不可靠。

如果测试因网络连接超时或失败怎么办？

测试和S3A客户端设计为可配置不同的超时设置。如果您发现问题且此配置无效，这表明配置机制尚不完善。如果在生产代码中出现这种情况，可能预示着在长距离连接中会暴露问题。请协助我们识别并修复这些问题——尤其是您最适合验证修复是否有效。

文件 core-site.xml

该文件预先存在，并引用了在auth-keys.xml下创建的配置。

在大多数情况下，除非您需要在测试期间应用特定的非默认属性更改，否则您无需编辑此文件。

文件 auth-keys.xml

该文件的存在会触发对S3类的测试。

如果没有这个文件，该模块中的所有集成测试都不会被执行。

XML文件必须包含连接每个文件系统客户端到对象存储所需的所有ID/密钥信息，以及每个文件系统用于测试的URL。

1. test.fs.s3a.name : S3a测试所用的存储桶URL
2. fs.contract.test.fs.s3a : 用于S3a文件系统合约测试的存储桶URL

测试过程中，存储桶的内容将被销毁：请勿将此存储桶用于测试以外的任何用途。此外，对于s3a，测试开始时将中止所有进行中的多部分上传（通过强制设置fs.s3a.multipart.purge=true）以清理之前失败测试的临时状态。

示例：

<configuration>

  <property>
    <name>test.fs.s3a.name</name>
    <value>s3a://test-aws-s3a/</value>
  </property>

  <property>
    <name>fs.contract.test.fs.s3a</name>
    <value>${test.fs.s3a.name}</value>
  </property>

  <property>
    <name>fs.s3a.access.key</name>
    <description>AWS access key ID. Omit for IAM role-based authentication.</description>
    <value>DONOTCOMMITTHISKEYTOSCM</value>
  </property>

  <property>
    <name>fs.s3a.secret.key</name>
    <description>AWS secret key. Omit for IAM role-based authentication.</description>
    <value>DONOTEVERSHARETHISSECRETKEY!</value>
  </property>

  <property>
    <name>test.sts.endpoint</name>
    <description>Specific endpoint to use for STS requests.</description>
    <value>sts.amazonaws.com</value>
  </property>

</configuration>

默认加密

可以在AWS端为存储桶配置默认加密。当启用默认加密时，由于ETags生成方式的不确定性，会跳过部分S3AFileSystem测试。

禁用加密测试

如果S3存储/存储类别不支持服务器端加密，这些操作将会失败。可以关闭这些功能。

<property>
  <name>test.fs.s3a.encryption.enabled</name>
  <value>false</value>
</property>

加密仅用于类名中包含Encryption的特定测试套件。

针对不同区域的测试

S3A可以连接到不同区域——测试支持此功能。只需在auth-keys.xml中定义目标区域即可。

<property>
  <name>fs.s3a.endpoint.region</name>
  <value>eu-central-1</value>
</property>

CSV数据测试

TestS3AInputStreamPerformance测试需要读取一个多MB的文本文件。这些测试默认使用的公共文件来自NOAA Continuously Operating Reference Stations (CORS) Network (NCN)，路径为s3a://noaa-cors-pds/raw/2023/001/akse/AKSE001a.23_.gz

过去要求必须使用csv.gz文件来验证S3 Select支持。现在由于S3 Select支持已被移除，可以使用其他大型文件替代。

该对象的路径在选项 fs.s3a.scale.test.csvfile 中设置，

<property>
  <name>fs.s3a.scale.test.csvfile</name>
  <value>s3a://noaa-cors-pds/raw/2023/001/akse/AKSE001a.23_.gz</value>
</property>

1. 如果未覆盖该选项，则使用默认值。该服务托管在亚马逊的美国东部数据中心。
2. 如果fs.s3a.scale.test.csvfile为空，则依赖该文件的测试将被跳过。
3. 如果由于任何原因无法读取数据，则测试将失败。
4. 如果该属性设置为不同的路径，则该数据必须可读且“足够”大。
5. 如果是.gz文件，预计会出现与解压缩相关的测试失败。

(需要空格或换行的原因是添加“一个空条目”；空的会被视为未定义并采用默认值)

如果在不同的AWS S3区域使用测试文件，则必须定义特定于存储桶的区域。对于托管在noaa-cors-pds存储桶中的默认测试数据集，配置如下：

  <property>
    <name>fs.s3a.bucket.noaa-cors-pds.endpoint.region</name>
    <value>us-east-1</value>
  </property>

测试访问点集成

S3a支持使用访问点ARN来访问S3中的数据。如果您认为您的更改会影响VPC集成、请求签名、ARN操作或任何涉及实际向S3发送和从S3检索数据的代码路径，请确保在启用此功能的情况下运行整个集成测试套件。

查看我们的文档了解如何启用此功能的步骤。要为您的S3存储桶创建访问点，您可以使用AWS控制台或CLI。

启用标记审计功能

要启用对每个测试套件输出目录的审计功能，请启用选项 fs.s3a.directory.marker.audit

-Dfs.s3a.directory.marker.audit=true

设置后，如果标记策略是删除测试输出目录下的标记，则将运行标记工具审计命令。如果发现标记，此操作将失败。

这会给每个操作增加额外开销，但有助于验证连接器不会在需要删除标记的位置保留标记——从而保持向后兼容性。

启用规模测试

如果Maven构建中设置了scale属性，则会启用测试，无论是否使用了并行测试配置文件都可以这样做

mvn verify -Dscale

mvn verify -Dparallel-tests -Dscale -DtestsThreadCount=8

最占用带宽的测试（那些上传数据的测试）总是按顺序运行；由于HTTPS设置成本或服务器端操作而较慢的测试则包含在并行测试集中。

通过Maven调整规模选项

部分测试可以通过Maven构建或运行测试时使用的配置文件进行调整。

mvn verify -Dparallel-tests -Dscale -DtestsThreadCount=8 -Dfs.s3a.scale.test.huge.filesize=128M

该算法是

1. 该值从配置文件中查询，如果未设置则使用默认值。
2. 该值是从JVM系统属性中查询获取的，由maven传递下来。
3. 如果系统属性为null、空字符串或其值为unset，则使用配置值。unset选项用于解决maven属性传播中的一个特殊问题。

只有少数属性可以通过这种方式设置；未来会添加更多。

文件和分区大小是带有k/m/g/t/p后缀的数值，具体取决于所需大小。例如：128M、128m、2G、2G、4T甚至1P。

扩展测试配置选项

一些规模测试会执行多项操作（例如创建多个目录）。

要执行的操作的确切数量可在选项scale.test.operation.count中配置

<property>
  <name>scale.test.operation.count</name>
  <value>10</value>
</property>

较大的值会产生更大的负载，建议在本地测试或批量运行时使用。

较小的值会加快测试运行速度，尤其是当对象存储距离较远时。

对目录进行操作的功能有一个单独的选项：用于控制创建递归目录时的测试宽度和深度。数值越大，创建的目录数量会呈指数级增长，从而影响性能。

<property>
  <name>scale.test.directory.count</name>
  <value>2</value>
</property>

针对S3A的DistCp测试支持可配置的文件大小。默认值为10 MB，但配置值以KB表示，以便可以调小以实现更快的测试运行。

<property>
  <name>scale.test.distcp.file.size.kb</name>
  <value>10240</value>
</property>

以下是S3A特定的扩展测试属性

fs.s3a.scale.test.huge.filesize: "超大文件测试"的大小（以MB为单位）。

Huge File测试验证了S3A处理大文件的能力——属性fs.s3a.scale.test.huge.filesize声明了要使用的文件大小。

<property>
  <name>fs.s3a.scale.test.huge.filesize</name>
  <value>200M</value>
</property>

Amazon S3对大文件（超过5GB）的处理方式与小文件不同。将超大文件大小设置为大于该值的数字可验证对大文件的支持。

<property>
  <name>fs.s3a.scale.test.huge.filesize</name>
  <value>6G</value>
</property>

这种规模的测试速度较慢：最好在运行于云基础设施中的主机上执行，其中S3端点位于该基础设施中。否则，请在fs.s3a.scale.test.timeout中设置较大的超时值。

<property>
  <name>fs.s3a.scale.test.timeout</name>
  <value>432000</value>
</property>

测试按特定顺序执行，以确保仅在全部测试结束后才清理生成的文件。如果测试被中断，测试数据将保留。

并行CI构建。

对于该模块的CI测试，包括集成测试，通常需要支持同时测试多个PR。

要实现这一点：1. 必须在job.id属性中提供一个作业ID，这样每个作业都能在独立的目录树中运行。这应该是一个数字或唯一字符串，将用作路径元素，因此只能包含S3/hadoop路径元素中有效的字符。2. 需要通过将fs.s3a.root.tests.enabled设置为false来禁用根目录测试，可以在maven命令行或XML配置中进行设置。

mvn verify -T 1C -Dparallel-tests -DtestsThreadCount=14 -Dscale -Dfs.s3a.root.tests.enabled=false -Djob.id=001

此并行执行功能仅适用于共享单个S3存储桶的隔离构建；不支持来自同一本地源代码树的并行构建和测试。

在不执行根测试的情况下，设置一个定时任务定期清理测试存储桶中的所有数据，以降低成本。最简单的方法是为存储桶设置生命周期规则，删除超过几天的所有文件，同时终止所有超过24小时的待处理上传。

保护CI构建安全

在CI基础设施中使用AWS凭证测试提交到Apache GitHub账户的PR显然是不安全的——这就是为什么Yetus发起的构建不会这样做。

任何私下进行此操作的人员应：* 在触发测试前审查传入的补丁。* 拥有一个专用的IAM角色，该角色对测试存储桶、使用的任何KMS密钥以及包含CSV测试文件的外部存储桶具有受限访问权限。* 建立一个构建流程，为该角色生成短期会话凭据。* 在EC2虚拟机/容器中运行测试，该虚拟机/容器从IAM实例/容器凭据提供程序收集受限的IAM凭据。

测试中使用的公共数据集

部分测试依赖于Amazon S3上现有的公开数据集。您可以在org.apache.hadoop.fs.s3a.test.PublicDatasetTestUtils中找到其中一些数据集。

当测试不属于Amazon S3标准商业分区(aws)的端点时，例如第三方实现或AWS中国区域，您应该将这些配置替换为空()以禁用测试，或替换为对象存储中支持这些测试的现有路径。

例如，MarkerTools测试可能需要一个包含大量对象的存储桶，或者请求者支付测试需要为存储桶启用请求者支付功能。

禁用存储类测试

当针对不支持S3存储类别的第三方对象存储运行存储类别测试时，这些测试可能会失败。可以禁用它们。

<property>
  <name>test.fs.s3a.create.storage.class.enabled</name>
  <value>false</value>
</property>

配置CSV文件读取测试

要在支持相同API的替代基础设施上进行测试，必须将选项fs.s3a.scale.test.csvfile设置为" "，或者将一个至少10MB的对象上传到对象存储中，并将fs.s3a.scale.test.csvfile选项设置为其路径。

<property>
  <name>fs.s3a.scale.test.csvfile</name>
  <value> </value>
</property>

(是的，这个空格是必要的。Hadoop Configuration 类会将空值视为"不覆盖默认值")。

为所有测试启用预取

如果Maven构建中设置了prefetch属性，测试将在预取模式下运行。这也可以与规模测试结合使用。

如果ITestS3AContractGetFileStatusV1List因任何关于不支持的API的错误而失败。

  <property>
    <name>test.fs.s3a.list.v1.enabled</name>
    <value>false</value>
  </property>

注意：没有对应的关闭v2列表API的选项，现在所有存储都必须支持该功能。

测试请求者付费

默认情况下，请求者支付测试将在亚马逊S3的us-east-1区域寻找存在的存储桶。

如果终端节点支持请求者付费，您可以指定一个替代对象。测试仅需要一个至少几字节大小的对象，以验证列表和基本读取功能是否正常工作。

<property>
  <name>test.fs.s3a.requester.pays.file</name>
  <value>s3a://my-req-pays-enabled-bucket/on-another-endpoint.json</value>
</property>

如果端点不支持请求者付费，您也可以通过将测试URI配置为单个空格来禁用测试。

<property>
  <name>test.fs.s3a.requester.pays.file</name>
  <value> </value>
</property>

测试会话凭证

部分测试会从AWS安全令牌服务请求会话凭证和假定角色凭证，然后直接或通过委托令牌使用这些凭证与S3进行身份验证。

如果S3实现不支持STS，则必须禁用这些功能测试用例：

<property>
  <name>test.fs.s3a.sts.enabled</name>
  <value>false</value>
</property>

这些测试从STS服务端点请求一组临时凭证。可以在fs.s3a.assumed.role.sts.endpoint中定义备用端点。如果设置了此参数，则还必须在fs.s3a.assumed.role.sts.endpoint.region中定义委托令牌区域。这不仅有助于测试替代基础设施，还能减少远离中心服务执行的测试延迟。

<property>
  <name>fs.s3a.delegation.token.endpoint</name>
  <value>fs.s3a.assumed.role.sts.endpoint</value>
</property>
<property>
  <name>fs.s3a.assumed.role.sts.endpoint.region</name>
  <value>eu-west-2</value>
</property>

默认为""；表示“使用亚马逊默认端点”（sts.amazonaws.com）。

请查阅AWS文档获取完整的位置列表。

禁用内容编码测试

ITestS3AContentEncoding中的测试可能需要禁用

  <property>
    <name>test.fs.s3a.content.encoding.enabled</name>
    <value>false</value>
  </property>

可能失败的测试（可以忽略）

• ITestS3AContractMultipartUploader 测试 testMultipartUploadAbort 和 testSingleUpload 抛出 FileNotFoundException
• ITestS3AMiscOperations.testEmptyFileChecksums：如果文件系统始终加密数据。

子类化现有的共享基类

除非有充分理由，否则请扩展AbstractS3ATestBase或AbstractSTestS3AHugeFiles。这些基类会为对象存储测试做好配置，提供良好的线程命名，帮助生成隔离路径。对于AbstractSTestS3AHugeFiles的子类，只有在设置了-Dscale参数时才会运行。

AbstractS3ATestBase的主要特性

• getFileSystem() 返回绑定到合约测试文件系统的S3A文件系统，该文件系统定义在fs.s3a.contract.test中
• 如果该URL未设置，将自动跳过所有测试。
• 扩展 AbstractFSContractTestBase 和 Assert 的所有方法。

共享基类也有助于减少未来的维护工作。请使用它们。

安全

切勿记录凭证。凭证测试特意避免提供有意义的日志或断言消息，正是为了防止这种情况。

高效节省时间和金钱

这意味着在测试设置/拆卸方面高效，并且理想情况下利用现有的公共数据集以节省设置时间和测试人员成本。

特别值得注意的策略包括：

1. ITestS3ADirectoryPerformance: 单个测试用例会先设置目录树结构，然后执行不同的列表操作并测量耗时。
2. AbstractSTestS3AHugeFiles: 将测试套件标记为@FixMethodOrder(MethodSorters.NAME_ASCENDING)，然后对测试用例进行排序，使每个测试用例都期望前一个测试已完成（此处指上传文件、重命名文件等操作）。这既能在报告中提供独立的测试结果，又允许执行有序的操作序列。请注意使用Assume.assume()来检测单个测试用例的前提条件是否满足，因此测试会被跳过，而不是因误报的跟踪信息而失败。

AbstractSTestS3AHugeFiles的有序测试用例机制可能是链接测试设置/拆卸的最优雅方式。

关于重用现有数据，我们倾向于使用AWS美国东部区域的noaa-cors-pds存档来测试输入流操作。这不适用于其他区域或第三方S3实现。因此，URL可以被覆盖以在其他地方进行测试。

与其他S3存储兼容

不要假设仅使用AWS S3美国东部区域，需确保能与外部S3实现方案兼容。这些外部实现可能不支持最新的S3 API功能，例如加密、会话API等特性。

它们不会拥有相同的CSV/大型测试文件，因为部分输入测试依赖于这些文件。查看ITestS3AInputStreamPerformance了解如何编写测试以支持在替代文件系统上声明特定的大型测试文件。

适用于长距离链路

除了使文件大小和操作计数可扩展外，这还包括设置适当的测试超时时间。Scale测试使这一配置成为可能；在AbstractS3ATestBase()中硬编码为十分钟；子类可以通过重写getTestTimeoutMillis()来更改此设置。

同样重要的是：支持代理，因为一些测试人员需要它们。

提供诊断和计时信息

1. 为线程设置有用的名称。
2. 创建日志，记录信息。要知道S3AFileSystem及其输入输出流全部都在它们的{{toString()}}调用中提供了有用的统计信息；记录这些信息本身就很有价值。
3. 你可以在这里使用AbstractS3ATestBase.describe(format-stringm, args)；它会添加一些换行符以便更容易识别。
4. 使用ContractTestUtils.NanoTimer来测量操作持续时间，并记录输出日志。

有意义地失败

ContractTestUtils 类包含一整套断言方法，用于对文件系统的预期状态进行声明，例如 assertPathExists(FS, path)、assertPathDoesNotExists(FS, path) 等。这些方法会尽力在失败时提供有意义的诊断信息（如目录列表、文件状态等），从而帮助更轻松地理解故障原因。

至少，在使用assertTrue()或assertFalse()时不要不包含错误信息。

设置其文件系统并检查这些设置

测试可以重写createConfiguration()方法，以向测试中使用的S3A文件系统实例的配置文件中添加新选项。

然而，文件系统缓存可能导致测试套件获取到一个使用不同配置创建的缓存实例。对于不需要特定配置的测试来说，缓存是有益的：它能减少测试准备时间。

对于那些确实需要独特选项（加密、魔法文件）的测试，可能会出现故障，而且这些故障会以难以复现的方式发生。

在修改配置时，使用S3ATestUtils.disableFilesystemCaching(conf)来禁用缓存。例如来自AbstractTestS3AEncryption的示例：

@Override
protected Configuration createConfiguration() {
  Configuration conf = super.createConfiguration();
  S3ATestUtils.disableFilesystemCaching(conf);
  removeBaseAndBucketOverrides(conf,
      SERVER_SIDE_ENCRYPTION_ALGORITHM);  
  conf.set(Constants.SERVER_SIDE_ENCRYPTION_ALGORITHM,
          getSSEAlgorithm().getMethod());
  return conf;
}

然后在设置方法或测试用例中验证其文件系统是否确实具备所需功能（fs.getConf().getProperty(...)）。这不仅能发现文件系统重用问题，还能检测到auth-keys.xml中文件系统配置存在显式的每存储桶设置（这些设置会覆盖测试套件的通用选项配置）的情况。

清理后续工作

降低成本。

1. 不仅要在测试用例成功完成时进行清理；测试套件的拆卸也必须完成清理。
2. 在清理之前，该拆卸代码必须检查文件系统和其他字段是否为null。为什么？如果测试设置失败，拆卸方法仍然会被调用。

稳定可靠运行

我们对此深表感激——您也会的。

除非不可行，否则并行运行。

测试必须设计为能与其他测试并行运行，所有测试都使用同一个共享的S3存储桶。这意味着

• 使用由方法AbstractFSContractTestBase.path(String filepath)提供的相对路径和JVM分支唯一路径。
• 不操作根目录或对其内容做出断言（例如：删除其内容并断言现在为空）。
• 对存储桶的所有活跃客户端没有特定要求（例如：SSE-C测试要求所有文件，包括目录标记，都必须使用相同的密钥加密）。
• Doesn’t use so much bandwidth that all other tests will be starved of IO and start timing out (e.g. the scale tests).

此类测试只能作为顺序测试运行。添加测试时，需先在POM文件中将其从并行failsafe运行中排除，之后再添加到顺序测试中。涉及大量IO操作的测试还必须继承S3AScaleTestBase基类，因此仅当系统/Maven属性fs.s3a.scale.test.enabled为true时才会执行。

可以在集成开发环境(IDE)中运行单个测试用例

这对于调试测试失败非常宝贵。

如何在您的hadoop配置中设置测试选项，而不是在maven命令行上设置：

控制AWS成本

大多数基础的S3测试在设计时都会在测试运行后删除文件，因此您无需支付存储费用。规模测试会处理更多数据，因此成本更高，执行时间通常也更长。

然而您需要支付费用

1. 测试运行后留在S3中的数据。
2. 对文件的HTTP操作（HEAD、LIST、GET）。
3. 来自批量IO或S3A提交器测试的进行中的多部分上传。
4. 使用AWS KMS密钥进行加密/解密。

每次对文件进行部分读取时都会产生GET/decrypt开销，因此随机IO可能比顺序IO成本更高；但列式数据对查询的加速效果通常能弥补这一开销。

如何降低成本

• 不要使用大型数据集运行规模测试；保持fs.s3a.scale.test.huge.filesize未设置，或设置为几MB（最小值：5）。
• 删除文件系统中的所有文件。根测试通常会执行此操作，但也可以手动完成：

  *hadoop fs -rm -r -f -skipTrash s3a://test-bucket/

• 中止所有未完成的上传：

  hadoop s3guard uploads -abort -force s3a://test-bucket/

如何确保您的凭证真正安全

尽管auth-keys.xml文件在git和subversion中被标记为忽略，但它仍然存在于您的源代码树中，始终存在泄露的风险。

您可以通过将密钥保留在源代码树之外并使用绝对XInclude引用来避免这种情况。

<configuration>

  <include xmlns="http://www.w3.org/2001/XInclude"
    href="file:///users/ubuntu/.auth-keys.xml" />

</configuration>

基础命令行回归测试

我们需要对CLI进行一次全面检查，看看是否存在导致问题的变更，特别是是否出现了新的日志消息，或者某些打包更改是否破坏了该CLI。

在执行此操作时启用IOStatistics报告总是很有趣

<property>
  <name>fs.iostatistics.logging.level</name>
  <value>info</value>
</property>

从项目根目录开始，创建一个命令行发布版本 mvn package -Pdist -DskipTests -Dmaven.javadoc.skip=true -DskipShade;

1. 进入 hadoop-dist/target/hadoop-x.y.z-SNAPSHOT 目录。
2. 将core-site.xml文件复制到etc/hadoop目录中。
3. 在命令行或~/.hadoop-env文件中设置HADOOP_OPTIONAL_TOOLS环境变量。

export HADOOP_OPTIONAL_TOOLS="hadoop-aws"

运行一些基本的s3guard命令行工具以及文件操作。

export BUCKETNAME=example-bucket-name
export BUCKET=s3a://$BUCKETNAME

bin/hadoop s3guard bucket-info $BUCKET

bin/hadoop s3guard uploads $BUCKET
# repeat twice, once with "no" and once with "yes" as responses
bin/hadoop s3guard uploads -abort $BUCKET

# ---------------------------------------------------
# root filesystem operatios
# ---------------------------------------------------

bin/hadoop fs -ls $BUCKET/
# assuming file is not yet created, expect error and status code of 1
bin/hadoop fs -ls $BUCKET/file

# exit code of 0 even when path doesn't exist
bin/hadoop fs -rm -R -f $BUCKET/dir-no-trailing
bin/hadoop fs -rm -R -f $BUCKET/dir-trailing/

# error because it is a directory
bin/hadoop fs -rm $BUCKET/

bin/hadoop fs -touchz $BUCKET/file
# expect I/O error as it is the root directory
bin/hadoop fs -rm -r $BUCKET/

# succeeds
bin/hadoop fs -rm -r $BUCKET/\*

# ---------------------------------------------------
# File operations
# ---------------------------------------------------

bin/hadoop fs -mkdir $BUCKET/dir-no-trailing
bin/hadoop fs -mkdir $BUCKET/dir-trailing/
bin/hadoop fs -touchz $BUCKET/file
bin/hadoop fs -ls $BUCKET/
bin/hadoop fs -mv $BUCKET/file $BUCKET/file2
# expect "No such file or directory"
bin/hadoop fs -stat $BUCKET/file

# expect success
bin/hadoop fs -stat $BUCKET/file2

# expect "file exists"
bin/hadoop fs -mkdir $BUCKET/dir-no-trailing
bin/hadoop fs -mv $BUCKET/file2 $BUCKET/dir-no-trailing
bin/hadoop fs -stat $BUCKET/dir-no-trailing/file2
# treated the same as the file stat
bin/hadoop fs -stat $BUCKET/dir-no-trailing/file2/
bin/hadoop fs -ls $BUCKET/dir-no-trailing/file2/
bin/hadoop fs -ls $BUCKET/dir-no-trailing
# expect a "0" here:
bin/hadoop fs -test -d  $BUCKET/dir-no-trailing ; echo $?
# expect a "1" here:
bin/hadoop fs -test -d  $BUCKET/dir-no-trailing/file2 ; echo $?
# will return NONE unless bucket has checksums enabled
bin/hadoop fs -checksum $BUCKET/dir-no-trailing/file2
# expect "etag" + a long string
bin/hadoop fs -D fs.s3a.etag.checksum.enabled=true -checksum $BUCKET/dir-no-trailing/file2
bin/hadoop fs -expunge -immediate -fs $BUCKET

# ---------------------------------------------------
# Delegation Token support
# ---------------------------------------------------

# failure unless delegation tokens are enabled
bin/hdfs fetchdt --webservice $BUCKET secrets.bin
# success
bin/hdfs fetchdt -D fs.s3a.delegation.token.binding=org.apache.hadoop.fs.s3a.auth.delegation.SessionTokenBinding --webservice $BUCKET secrets.bin
bin/hdfs fetchdt -print secrets.bin

# expect warning "No TokenRenewer defined for token kind S3ADelegationToken/Session"
bin/hdfs fetchdt -renew secrets.bin


# ---------------------------------------------------
# Copy to from local
# ---------------------------------------------------

time bin/hadoop fs -copyFromLocal -t 10  share/hadoop/tools/lib/*aws*jar $BUCKET/

# expect the iostatistics object_list_request value to be O(directories)
bin/hadoop fs -ls -R $BUCKET/

# expect the iostatistics object_list_request and op_get_content_summary values to be 1
bin/hadoop fs -du -h -s $BUCKET/

mkdir tmp
time bin/hadoop fs -copyToLocal -t 10  $BUCKET/\*aws\* tmp

# ---------------------------------------------------
# Cloudstore
# check out and build https://github.com/steveloughran/cloudstore
# then for these tests, set CLOUDSTORE env var to point to the JAR
# ---------------------------------------------------

bin/hadoop jar $CLOUDSTORE storediag $BUCKET

time bin/hadoop jar $CLOUDSTORE bandwidth 64M $BUCKET/testfile

其他测试

• 无论您有哪些使用S3A的应用程序：在升级前构建并运行它们。然后观察升级完成后它们是否能在大致相同的时间内成功完成。
• 测试您有权访问的任何第三方端点。
• 尝试不同的区域（特别是仅支持IPv4的区域）和加密设置。
• 您进行的任何性能测试都可以识别出速度下降的情况，这可能是SDK行为发生变化的信号（特别是在流读取和写入时）。
• 如果可能，尝试在需要通过代理与AWS服务通信的环境中进行测试。
• 尝试让其他人，特别是那些拥有自己终端、应用或不同部署环境的人，运行他们自己的测试。
• 运行负载测试，尤其是ILoadTestS3ABulkDeleteThrottling。
• 检出cloudstore，针对您的hadoop版本进行构建，然后使用其CLI运行一些命令（storediag等）

处理已弃用的API和新功能

Jenkins运行会告诉你是否有新的弃用内容。如果有，你应该考虑如何处理它们。

迁移到之前SDK版本中不存在的方法和API，使得在出现问题时更难回滚；但弃用这些内容可能有充分的理由。

与此同时，继续使用旧代码可能有充分的理由。

• AWS采用了构建器模式来创建新操作；请注意，以此方式构建的对象通常会禁用其（现有的）setter方法；这可能会破坏现有代码。
• S3调用的新版本（列表v2、存储桶存在性检查、批量操作）可能比之前的HTTP操作和API更好，但它们可能无法与第三方端点兼容，因此只有在可选的情况下才能采用，这又会增加一个新的配置选项（包括文档、测试等）。此类变更必须在其自己的补丁中完成，并附带比较新旧操作的新测试。

提交补丁

当补丁提交时：将JIRA更新为实际使用的版本号；在提交信息中使用该标题。

准备好回滚、重新迭代或编写代码以解决回归问题。

随着更广泛的使用，可能会出现一些问题，这些问题可以在新的AWS版本中得到修复，回滚到旧版本，或者通过HADOOP-14596进行解决。

如果发生这种情况，请不要惊讶，也不必过于担心。虽然回滚选项可供使用，但理想情况下应尽量向前推进。

如果问题出在SDK上，请在AWS V2 SDK Bug tracker提交问题。如果问题可以通过Hadoop代码修复或解决，也请在那里进行处理。