Traceback (most recent call last):
File "D02.py", line 852, in <module>
configure_logging()
File "D02.py", line 66, in configure_logging
logging.basicConfig(level=logging.DEBUG, format='%(asctime)s - %(levelname)s - %(message)s', filename=lo g_file)
File "/usr/local/python3/lib/python3.6/logging/__init__.py", line 1808, in basicConfig
h = FileHandler(filename, mode)
File "/usr/local/python3/lib/python3.6/logging/__init__.py", line 1032, in __init__
StreamHandler.__init__(self, self._open())
File "/usr/local/python3/lib/python3.6/logging/__init__.py", line 1061, in _open
return open(self.baseFilename, self.mode, encoding=self.encoding)
OSError: [Errno 28] No space left on device: '/u01/auszfe/projects/Water_Data/logs_D02_10.7.132.30_10000/202 3-09-05_09-15.log'
这个错误提示表明你的设备上的存储空间已满，无法创建新的日志文件。要解决这个问题，你可以考虑以下几个步骤：
-
清理磁盘空间：首先，你需要清理一些不必要的文件或者移动一些大文件到其他位置，以腾出足够的磁盘空间。可以使用一些系统命令或者工具来查看磁盘使用情况和删除不必要的文件。
-
调整日志文件大小限制：你的代码中有一段检查日志文件大小的逻辑，如果超过2MB就创建新的日志文件。你可以考虑调整这个大小限制，让日志文件不那么频繁地创建新的文件，或者将旧的日志文件备份到其他位置。
-
日志文件定期清理：你的代码中有一段清理旧日志文件的逻辑，但它只会删除创建时间超过180天的文件。你可以考虑定期清理一些较旧的日志文件，以减少磁盘空间的占用。
-
检查磁盘配额：如果你使用的是网络文件系统或者有磁盘配额限制的环境，确保你没有超出磁盘配额限制。
-
检查磁盘健康状态：有时磁盘本身可能存在问题，导致无法写入数据。你可以使用磁盘检查工具来检查磁盘的健康状态。
完成这些步骤后，重新运行你的代码，应该就不会再遇到 “No space left on device” 的错误了。如果问题仍然存在，你可能需要考虑扩展磁盘空间或更换硬盘。
目前是删除什么时候的日志？
根据你提供的代码，日志的删除时间是根据文件的创建时间来决定的，具体来说，是根据文件名中的时间部分来判断是否删除。以下是代码中的相关部分：
# 如果文件创建时间早于 180 天前，就删除
if current_time - creation_time > (30 * 24 * 60 * 60):
file_path = os.path.join(log_path, file_name)
os.remove(file_path)
上述代码中，如果一个日志文件的创建时间早于180天前（30 * 24 * 60 * 60秒），则会被删除。
这意味着你的日志文件会保留180天，然后会自动删除旧的日志文件。如果你想修改保留日志的时间期限，你可以更改条件中的时间差值，例如，将 (30 * 24 * 60 * 60) 修改为你希望的天数的秒数。
请注意，根据你的需求，你可以调整这个时间期限，以适应你的日志保留策略。如果你想保留更长时间的日志，可以增加这个时间差值，反之亦然。
但是我应该没有限制log总共的大小吧，为什么还会报错呢？
如果你没有设置日志总大小的限制，那么报错可能是由于磁盘空间不足导致的。虽然你没有明确限制日志总大小，但是日志文件可能会随着时间的推移不断增大，最终导致磁盘空间不足。
在你的代码中，有一段检查日志文件大小并创建新日志文件的逻辑：
if log_size > 2 * 1024 * 1024:
# 创建新的日志文件
new_log_filepath = create_new_log()
这段代码会在日志文件大小超过2MB时创建一个新的日志文件。如果你的应用程序一直在写入大量的日志数据，并且没有限制，那么这个检查可能会触发频繁创建新的日志文件，导致磁盘空间逐渐耗尽。
为了解决这个问题，你可以考虑以下几个选项：
-
增加磁盘空间： 如果你有权限并且磁盘空间不足，可以考虑增加磁盘空间，以容纳更多的日志数据。
-
限制日志文件大小： 可以限制单个日志文件的最大大小，以避免单个文件过大。你可以在
if log_size > 2 * 1024 * 1024:这个条件中设置一个更大的值，或者根据需要进行调整。 -
定期清理日志文件： 定期清理不再需要的旧日志文件，以释放磁盘空间。你可以编写一个定期运行的任务或脚本来完成这个任务，确保不会占用太多磁盘空间。
-
使用日志轮换工具： 考虑使用专门的日志轮换工具，如
logrotate（对于Linux系统）或其他类似工具，它们可以自动管理和清理日志文件，以防止磁盘空间不足的问题。
根据你的需求和应用程序的特性，你可以选择以上任何一种或多种方法来解决磁盘空间不足的问题。
我限制了数量 if len(log_files) >= 86400
理解了，你在代码中限制了日志文件的数量，当日志文件数量达到86400个或更多时，会删除最旧的日志文件。这种做法是一种有效的控制策略，以防止日志文件数量无限增长，但仍然需要关注磁盘空间的问题。
在这种情况下，如果报错仍然是磁盘空间不足导致的，那么可能是因为：
-
日志文件大小较大：即使数量有限制，但如果每个日志文件都很大，仍然会导致磁盘空间不足。你可以检查日志文件的平均大小以及磁盘空间的剩余容量。
-
硬盘本身空间不足：即使你删除了旧的日志文件，如果硬盘的总空间非常有限，仍然可能会出现空间不足的问题。确保硬盘有足够的可用空间来存储新的日志文件。
-
其他进程或应用程序在同时占用磁盘空间：检查是否有其他进程或应用程序在同一磁盘上写入大量数据，导致磁盘空间被占满。
你可以通过以下方式来排除这些问题：
- 检查每个日志文件的大小，看是否有非常大的日志文件。
- 使用系统工具查看磁盘的可用空间情况。
- 检查是否有其他应用程序在占用磁盘空间。
如果日志文件大小适中，磁盘有足够的可用空间，并且没有其他进程占用磁盘空间，但仍然遇到空间不足的问题，那可能是系统或磁盘配置方面的问题，可能需要进一步调查。
如何查看当前磁盘分配了多少空间，linux
要查看当前磁盘分配了多少空间以及可用空间，你可以使用以下Linux命令：
df -h
这个命令会显示所有挂载的文件系统的磁盘使用情况，包括每个文件系统的总大小、已用空间、可用空间和挂载点。
在输出中，-h 参数表示以人类可读的格式显示磁盘大小，以更容易理解的单位（如GB、MB）显示磁盘使用情况。
示例输出可能如下所示：
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 30G 12G 16G 44% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/sdb1 100G 30G 70G 30% /data
在示例输出中，你可以看到不同文件系统的总大小（Size）、已用空间（Used）、可用空间（Avail）以及挂载点（Mounted on）。 Use% 列显示已使用空间的百分比。
从这个输出中，你可以很容易地查看每个文件系统的空间使用情况，以确定哪个文件系统的可用空间较少。
空间完全足够啊，为什么还是报错
[feeqpdata@AUSZPAI Water_Data]$ df -h /u01/auszfe/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vgu01-lvu01 100G 719M 95G 1% /u01
从你提供的磁盘使用信息来看，的确 /u01 文件系统的可用空间非常充足，因此 “No space left on device” 错误不应该是由于磁盘空间不足引起的。
这种情况下，可能的原因之一是文件系统配额限制或磁盘配额。文件系统配额可以限制每个用户或组在文件系统上的可用空间，即使整个文件系统的可用空间充足。要检查文件系统是否启用了配额限制，可以使用以下命令：
sudo quotacheck -vgum /u01
这个命令会检查 /u01 文件系统的磁盘配额情况。如果启用了磁盘配额，你可能需要调整相关配额限制，以确保你的应用程序可以继续写入日志文件。
另外，还可以检查文件系统的 inodes 配额。有时，即使磁盘空间足够，但如果 inodes 配额用尽，也可能导致无法创建新文件。你可以使用以下命令检查 inodes 配额情况：
df -i /u01
如果 inodes 配额用尽，你可能需要调整配额限制或者删除一些不必要的文件来释放 inodes。
如果以上检查都没有解决问题，可能需要进一步分析错误消息和日志，以确定具体的问题原因。可能需要查看应用程序的日志、系统日志等，以获取更多信息。如果问题仍然存在，可能需要进一步的系统调查。
查到了
[feeqpdata@AUSZPAI Water_Data]$ df -i /u01
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/vgu01-lvu01 102400 102400 0 100% /u01
根据你提供的信息，你的 /u01 文件系统的 inodes 配额已经用尽，导致无法创建新的文件。这就是报错的原因。
为了解决这个问题，你可以考虑以下几个选项：
-
清理不必要的文件: 首先，你可以查找并删除不再需要的文件，以释放
inodes。使用find命令可以帮助你找到大量的、不必要的文件。例如，你可以运行以下命令来查找并删除旧的日志文件：find /u01 -type f -name "*.log" -mtime +30 -exec rm {} \;上述命令会删除
/u01目录下30天前的所有以.log结尾的文件。 -
调整
inodes配额: 如果你需要更多的inodes配额，可以联系系统管理员或者使用tune2fs命令来调整。请谨慎操作，因为更改文件系统参数可能会有风险。例如，如果你希望将
inodes配额调整为200,000，可以运行以下命令（请确保在管理员权限下运行）：sudo tune2fs -i 200000 /dev/mapper/vgu01-lvu01这将把
/dev/mapper/vgu01-lvu01文件系统的inodes配额设置为200,000。 -
定期清理不必要的文件: 为了避免
inodes配额用尽的问题再次发生，建议定期清理不必要的文件，特别是日志文件、缓存文件等。 -
考虑将文件存储到其他文件系统: 如果
/u01的inodes配额仍然不足，你可以考虑将某些文件存储到其他文件系统，以分担负载。
请根据你的需求和文件系统的具体情况，选择适合你的解决方案。
根据你提供的信息，你的 /u01 文件系统总共分配了 102400 个 inodes。这是文件系统的 inodes 配额上限。然而，现在所有的 inodes 都已被使用，因此 inodes 配额用尽，无法再创建新的文件或目录。
为了解决这个问题，你可以采取我之前提到的措施之一，如清理不必要的文件、调整 inodes 配额或将文件存储到其他文件系统中。具体操作取决于你的需求和文件系统的用途。如果你需要更多的 inodes 配额，你可能需要联系系统管理员来协助调整文件系统的配置。
102400 是什么意思，10240KB？10240MB？
102400 是以 inodes 为单位的数字，它表示文件系统中可用的 inodes 数量。inodes 是用于存储文件和目录信息的数据结构，每个文件或目录都会占用一个 inode 条目。
与磁盘空间不同，inodes 不是以字节（如KB、MB）来衡量的，而是以数量来衡量。每个文件系统都分配一定数量的 inodes，并且在创建文件或目录时消耗一个 inode。
在你的情况下，文件系统 /dev/mapper/vgu01-lvu01 被分配了 102400 个 inodes，这意味着你可以在该文件系统上创建 102400 个文件或目录。当 inodes 用尽时，就无法再创建新的文件或目录，除非你释放一些 inodes 或者调整 inodes 配额。
因此，102400 不是以KB或MB来衡量的，而是指 inodes 的数量。你可以通过 df -i 命令来查看文件系统的 inodes 使用情况。
懂了，意思就是总文件的数量
是的，你理解得正确。inodes 的数量表示文件系统可以存储的总文件和目录数量。当 inodes 用尽时，就无法再创建新的文件或目录，除非你释放一些 inodes 或者调整 inodes 配额。这个数量是文件系统的一个重要限制，需要注意管理和维护，以确保不会用尽 inodes。
扫一扫
354
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
