你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

了解 Azure NetApp 文件中的目录大小

项目
08/14/2024

在目录中创建文件时，会将一个条目添加到 Azure NetApp 文件卷内的隐藏索引文件中。此索引文件有助于跟踪目录中现有的 inode，并有助于加速处理对包含大量文件的目录的查找请求。随着更多条目添加到此文件，文件大小会以每个条目大约 512 字节的速度增加（但不会减少），具体取决于文件名的长度。文件名越长，文件越大。符号链接也会向此文件添加条目。此概念被称为目录大小，它是所有基于 Linux 的文件系统中的共同要素。目录大小不是单个 Azure NetApp 文件卷中文件的最大总数。目录大小由 maxfiles 值决定。

默认情况下，创建新目录时，该目录会占用 4 KiB（4,096 字节），即 8 个 512 字节块。可以使用 stat 命令从 Linux 客户端查看新建目录的大小。

# mkdir dirsize 
# stat dirsize 
File: ‘dirsize’ 
Size: 4096            Blocks: 8          IO Block: 32768  directory

目录大小特定于单个目录，并且大小不会合并。例如，如果卷中有 10 个目录，则每个目录都会逐渐接近单个卷中 320 MiB 的目录大小限制。

确定目录是否将达限制大小

对于 320 MiB 的目录，块数为 655,360，每个块的大小为 512 字节。（即 320x1024x1024/512。）根据此数字，相当于一个 320 MiB 的目录最多可包含大约 400 万到 500 万个文件。但是，实际的最大文件数目可能更小，具体取决于多种因素，例如，目录中包含非 ASCII 字符的文件数。

可以从客户端使用 stat 命令来查看目录是否即将达到目录元数据的最大大小限制 (320 MB)。如果达到 Azure NetApp 文件的单个目录的最大大小限制，则会发生错误 No space left on device。

对于 320-MB 的目录，块数为 655,360，每个块的大小为 512 字节。（即 320x1024x1024/512。）根据此数字，相当于一个 320-MB 的目录最多可包含大约 400 万个文件。但是，实际的最大文件数目可能更小，具体取决于多种因素，例如，目录中包含非 ASCII 字符的文件数。有关如何监视 maxdirsize 的信息，请参阅监视 maxdirsize。

目录大小注意事项

处理高文件计数环境时，请考虑以下建议：

Azure NetApp 文件卷支持最大 320 MiB 的目录大小。此值无法增大。
一旦超出卷的目录大小，即使卷中有可用空间，客户端也会显示空间不足错误。
对于常规卷，320 MiB 目录大小相当于单个目录中的大约 400 万到 500 万个文件。此值取决于文件名的长度。
大型卷的体系结构与常规卷不同。
单个目录中的文件计数过高可能会导致搜索时出现性能问题。需要频繁搜索时，请尽可能地将单个目录的总大小限制为 2 MiB（大约 27,000 个文件）。
- 如果需要在单个目录中包含较多文件，请相应地调整搜索性能期望。虽然 Azure NetApp 文件会出于性能目的为目录文件列表编制索引，但如果文件计数过高，搜索可能需要花费一段时间。
设计文件系统时，请避免使用扁平目录布局。有关不同目录布局方法的信息，请参阅关于目录布局。
若要解决由于超出目录大小，因此无法创建新文件的问题，请删除或移出相关目录中的文件。

关于目录布局

使用扁平目录结构，并且其中的单个文件夹在单个级别包含数百万个文件时，maxdirsize 值可能会造成问题。文件、文件夹和子文件夹交错的文件夹结构对 maxdirsize 的影响较小。有多种目录结构方法。

扁平目录结构采用单个目录，这同一个目录下包含许多文件。

扁平目录结构图。

宽目录结构包含许多顶级目录，文件分布在所有目录中。

宽目录结构图。

深目录结构包含较少的顶级目录和较多的子目录。尽管这种结构在每个文件夹中提供较少的文件，但如果目录布局过深且文件路径过长，则文件路径长度可能会造成问题。有关文件路径长度的详细信息，请参阅了解 Azure NetApp 文件中的文件路径长度。

深目录结构图。

Azure NetApp 文件中扁平目录结构的影响

扁平目录结构（在单个或少量目录中包含许多文件）会对各种文件系统、Azure NetApp 文件卷等产生负面影响。潜在问题包括：

内存压力
CPU 使用率
网络性能/延迟（尤其是在执行大规模文件查询、GETATTR 操作、READDIR 操作期间）

由于 Azure NetApp 文件大型卷的设计，maxdirsize 的影响非常独特。 Azure NetApp 文件大型卷的 maxdirsize 因其设计而受到独特影响。与常规卷不同，大型卷使用 Azure NetApp 文件中的远程硬链接来帮助跨不同的存储设备重定向流量，以提供更大的可伸缩性和性能。使用扁平目录时，内部远程硬链接数与本地文件数的比例更高。这些远程硬链接计入总 maxdirsize 值，因此与常规卷相比，大型卷可能会更快地达到其 maxdirsize 限制。

例如，如果单个目录包含数百万个文件并为文件系统生成大约 85% 的远程硬链接，则达到 maxdirsize 限制的速度几乎是使用常规卷时的两倍。

为了最合理地利用 Azure NetApp 文件中的目录大小，请采取以下措施：

避免在 Azure NetApp 文件中使用扁平目录结构。如果文件或文件夹的路径长度不超过 NAS 协议标准，则最好使用宽或深目录结构。
如果不可避免地要使用扁平目录结构，请监视目录的 maxdirsize。

监视 `maxdirsize`

对于单个目录，请使用 stat 命令查找目录大小。

# stat /mnt/dir_11/c5

尽管 stat 命令可用于检查特定目录的目录大小，但针对单个目录单独运行该命令可能效率不高。以下命令会显示从大到小排序的最大目录大小列表，同时从查询中省略快照目录。

# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn

注意

stat 命令报告的目录大小以字节为单位。 find 命令中报告的大小以 KiB 为单位。

示例

# stat /mnt/dir_11/c5 

  File: ‘/mnt/dir_11/c5’ 

  Size: 322396160       Blocks: 632168     IO Block: 32768  directory 
 
# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn 
316084 /mnt/dir_11/c5 

3792 /mnt/dir_19 

3792 /mnt/dir_16

在前面的示例中，/mnt/dir_11/c5 的目录大小为 316,084 KiB (308.6 MiB)，接近 320 MiB 的限制。这相当于大约 410 万个文件。

# ls /mnt/dir_11/c5 | wc -l
4171624

在这种情况下，请考虑采取纠正措施，例如移动或删除文件。

通过