本文介绍弹性文件存储 EFS 数据流动功能相关的常见问题。
您可以在文件系统的监控告警页面查看相关信息,具体操作步骤如下:
- 在监控告警页面,选择带宽信息或 QPS 信息页签,查看相关数据。更多信息,请参见 EFS 告警指标说明。
为什么文件存在,但访问时短暂返回ESTALE错误,重试后又能正常访问?
- 执行数据流动的预热或淘汰任务时,会修改 EFS 文件的元数据。若业务在任务执行过程中并发访问正在处理的文件,可能引发元数据操作冲突,导致访问失败并返回ESTALE(文件句柄过期)错误。
- 预热场景:建议在业务访问前提前执行预热任务,确保数据完全加载至 EFS 后再提供服务。
- 淘汰场景:建议调整自动淘汰任务的执行时间窗口,避开业务高峰时段。
- 应急处理:若无法实现任务与业务时段隔离,可通过关闭并重新打开报错文件的方式恢复访问。
- 如果重试后问题仍未解决,请提交工单联系技术支持团队处理。
为什么文件存在,但访问时持续返回ESTALE错误,重试也无法正常访问?
- 当 EFS 侧仅存在文件元数据(数据尚未预热),而 TOS 侧对应的对象已被删除时,按需加载操作会持续返回ESTALE错误。
- 请检查 TOS 存储桶的生命周期配置,确认是否因生命周期规则设置过短导致对象被提前删除。如需保留数据,请调整生命周期规则并重新执行预热任务。
如何确定文件是否已成功预热至 EFS 文件系统或沉降至对象存储 TOS?
数据流动提供日志分析功能,支持实时查询和分析所有预热或沉降任务的执行记录。您可以通过以下方式开启该功能并查看任务执行状态:
开启该功能后,您可以在数据流动策略详情页的日志分析页签查看任务执行日志。更多信息,请参见查看数据流动日志。 文件预热至 EFS 或沉降至 TOS 失败的原因是什么?
- 自动预热与自动沉降存在分钟级别的延迟,延迟时间会随文件数量和集群业务压力增加而延长。
- 大文件的预热或沉降耗时与文件大小呈线性关系,超大文件可能需要小时级别的执行时间。
- 若小文件的任务执行时间超过 30 分钟,且已开启日志分析功能,您可以通过目标文件名称(对应日志字段file_name)搜索并查看失败日志,常见失败原因如下:
当数据流动预热或沉降任务性能压力过大,影响到 TOS 业务时,如何处理?
当前数据流动功能的带宽与文件系统带宽绑定,默认最多占用文件系统最大带宽的 30%。灵活调整数据流动带宽的流控能力正在开发中,敬请期待。
开启数据流动自动淘汰后,为什么显示的占用容量大于实际占用容量?
数据流动在实现淘汰功能时,会额外记录文件的访问时间等元数据信息,这部分元数据会占用少量存储空间,占用的容量与数据流动策略管理的文件数量成正比。
如何将同一份 EFS 数据沉降至多个 TOS Bucket,或者将同一份 TOS 数据预热至多个 EFS 文件系统?
您可以使用数据流动提供的自定义手动任务功能,将同一份数据逐个流动至不同的 TOS Bucket 或 EFS 文件系统。
- 当访问的文件数据仅存在于 TOS 侧时,需要通过按需加载机制从 TOS 侧读取数据,I/O 路径相对较长。如果业务是首次读取文件,可能会出现高延迟的情况。
- 对延迟敏感的业务场景,建议提前将需要访问的大文件预热至 EFS 文件系统。
当前数据流动自动同步功能仅支持以下 TOS 事件:
- tos:ObjectCreated:Origin
- tos:ObjectCreated:CompleteUpload
- tos:ObjectReplication:ObjectCreated
- tos:ObjectReplication:ObjectModified
- tos:ObjectRemoved:Delete
- tos:ObjectRemoved:DeleteMarkerCreated
- tos:LifecycleExpiration:Delete
- tos:LifecycleExpiration:DeleteMarkerCreated
为什么 TOS Bucket 或者 EFS 文件系统上的数据流动存在非预期的变化?
- 目前,文件存储 NAS、弹性文件存储 EFS 和文件存储 vePFS 均提供数据流动功能,如果同一个 TOS Bucket 同时与多个文件存储建立了数据流动关联,可能会出现非预期的数据变化。
- 为避免多个数据流动任务之间的数据覆盖,建议您在创建数据流动策略时,为不同的文件系统或 Bucket 配置不同的目标路径。
执行自定义预热任务后,硬链接文件访问异常是什么原因?
该问题是由硬链接的工作机制与数据流动预热的实现逻辑共同导致的:
硬链接通过共享同一个 inode 指向同一份数据块,多个硬链接文件本质上是同一数据的不同访问入口。当您通过数据流动功能从 TOS 预热其中一个硬链接文件时,EFS 会创建一个全新的独立文件并写入预热数据。此时,该新文件拥有独立的 inode,导致原有的硬链接关系被打破。因此,未被预热的其他硬链接文件将无法访问到预热后的数据。
TOS 桶未开启版本控制功能时,执行沉降或按需加载操作出现报错是什么原因?
- 当 TOS 桶未开启版本控制功能时,同名对象被覆盖后,原版本数据会被直接删除,导致数据流动相关操作无法找到所需的对象版本,从而引发操作失败。常见场景如下:
- 当 TOS 对象已完成一次预热后,如果您在 TOS 端上传同名新对象覆盖原对象,则需要重新执行预热任务,才能将新版本同步至 EFS。在重新预热完成前,若从 EFS 侧触发该文件的按需加载操作,则可能会失败。这是因为原 TOS 对象版本已被覆盖删除,而新版本尚未同步至 EFS,导致 EFS 无法找到对应的数据版本。
- 当 TOS 对象已完成一次预热,且 EFS 侧已加载该文件的部分数据后,如果您在 TOS 端上传同名新对象覆盖原对象,则执行沉降操作时可能会失败。这是因为沉降操作需要访问原 TOS 对象版本以完成数据回写,而该版本已被覆盖删除,导致沉降操作无法找到对应的源数据。
- 如果您的业务需要使用按需加载功能,且存在频繁更新 TOS 同名对象的场景,建议开启 TOS 桶的版本控制功能。开启后,TOS 会保留对象的历史版本,数据流动中的预热、沉降和按需加载操作将基于正确的对象版本执行,从而避免因对象覆盖导致的操作失败。