我们已经注意到netapp filer上的一个卷的问题。 似乎卷满了，NetApp通知说，卷正在使用或保留100％的空间（0％的inode） – 这是警告。 问题是，这不是这样的。 卷大小为190 GB。 卷是灵活的types，文件空间的保证，没有镜像。 我们在映射的卷上只有两个LUN。 95 GB和50 GB。 他们都设置为保留0％的快照。 两者都有空间预留。 数量上还有很多空间（理论上）。 df -r显示：
Filesystem kbytes used avail reserved Mounted on /vol/BACKUP/ 199229440 199229440 0 142799672 /vol/BACKUP/ 总体上还有一些可用空间。 我们有相同的聚合与LUN（相同的configuration）相似的卷，他们是完全正常的。 我们有新的架子，我们想要在那里迁移一些数据，在我们安装新的架子之前，我们要确保我们有所有数据的备份。 但是，由于这个，特定卷，备份失败（快照没有空闲空间）。
补充说：如果我检查生产系统上占用的空间，这两个LUN映射，它只有94 GB。
看看man vol ，阅读关于fractional reserve的一点 – 这是你的问题的根源。
特别是 – 当LUN空间不足时，它们会崩溃，并可能导致主机混乱。 NetApp允许您创build卷的快照 – 快照使用的空间与卷上更改的块成比例。 如果你的卷填满了，你不能分配新的块，因为有一个快照存在…你的LUN将全部中断。
因此，在分数储备，它说'每当我采取一个快照，储备体积空间，以便我不冒险跑出去'。 设置为100时，每个卷（存在快照时）都会尝试保留等于分配的LUN空间总和的空间，这意味着该卷必须是该大小的200％才能确保不会用完。
降低部分保留是一种风险，但如果不经常循环LUN中的所有数据，则风险不是很大。 请记住，耗尽将意味着写入LUN失败，这通常是坏消息。 您还可以调整音量保证选项 – file保证与fractional reserve 100组合意味着您的音量需要是内部LUN大小的200％（+一些，如果您有多个快照，虽然它不会是+100 ％每个快照）。
我看过这个问题。 在写入扇区时，LUN的工作方式是，这些扇区的原始内容将被分配，但不会从卷上清除，直到删除使用它们的快照为止。 在我的情况下，我并没有抢占LUN，但是我们发生了电源故障，而我们的UPS只覆盖了两个电源电路中的一个。 在这种情况下，NAS优先清理未使用的块。
最佳做法是在每个卷中放入一个LUN。 精简configurationLUN，然后在包含卷上设置自动增长。 我大量地configuration这些卷。 这意味着只要LUN仍然没有被使用，就永远不会遇到麻烦。 当每个扇区被写入时，它们开始大量覆盖，而不是脱机，卷将增长一点，以适应LUN增加的占用空间。 当然，服务器仍然会看到相同大小的LUN，所以一旦这个条件结束，空间利用率就会回落到正常水平。
精简configurationLUN的命令是lun set reservation lunpath disable 。 在卷上configuration自动增长的命令是vol autosize volname -m 100g -i 5g on （这会将最大值设置为100GB，并一次增加5GB）。