我已经实现了一个日志文件，该文件将在每分钟后存储进程的cpu和内存状态。我已将文件的最大大小限制为3MB（这足以达到我的目的）。
脚本将在每分钟后由cron作业调用，脚本将记录该分钟的详细信息，将文件重命名为“Log_.log”。
当大小达到“3MB - 100字节”时，我将文件指针重置为指向开始，并将覆盖日志文件中的第一个条目，现在将文件重命名为“Log_＆lt; 0 + some offset＆gt ;的.log“
由于我在每分钟后重命名文件以更新文件指针位置，这是一种好/有效的方法吗？
我不想为此目的维护多个日志文件。
我的另一个选择是将文件指针位置保存在文件中，但是....另一个文件!!如果这个选项好的话，不想保留一个：）
先谢谢。
答案 0 :(得分：4)
除非您输入的内容与您取出的内容完全相同，否则在文件中写入“in”实际上会导致写入位置后的整个后续部分被重写到磁盘。 追加便宜。
重命名文件以存储指针有效 - 但它不是很优雅，并且使事情变得更复杂（对于一个，您的进程需要对文件所在目录的写权限 - 否则只是写访问两个文件就足够了）
除非磁盘空间存在问题（实际上很少见），否则您的方法效率低于将所有内容附加到文件，并在文件达到其最大大小时旋转。这样，您始终可以使用最后3MB的日志，并且当前文件中最多可以增加3MB。它还可以使文件解析更容易，而不是重新计算整个指针位置。
每分钟（甚至每秒）重命名一个文件不应该显着降低系统速度，不要担心。
我们关注的主要是“您认为需要重命名文件的原因”。从技术角度来看，它并不是更好，从逻辑的角度来看并不是更好，它使许多其他（未来）任务变得更难。您可以将文件指针存储在单独的文件中，也可以存储在文件的末尾，并且有更好的^ H ^ H ^ H ^ H ^ H ^ H更简单的解决方案，根本不需要文件指针。
答案 1 :(得分：0)
我很困惑为什么要重命名你的文件。这实现了什么？
日志条目的大小是否固定？还是可变大小？
如果条目是固定大小的，那么从一开始就重写现有文件没有问题：您的文件中不会有不完整的条目，并且您正在为文件写入计数器或时间戳，应该清楚“光标”的位置。
如果条目是可变大小的，那么你可能不应该从头开始重写文件而不以某种方式明确'光标'在文件中的位置，并编写对读取截断日志有弹性的代码条目。
您可以重复使用现有工具，例如RRDtool吗？