确定“stat()”返回的有效时间戳精度

发布于 2024-11-26 13:26:36 字数 795 浏览 1 评论 0原文

我正在尝试确定软件中 struct statst_mtim.tv_nsec 字段对于特定目录/文件系统的有效精度。

有没有办法确定文件系统的修改时间精度(而不是库的“纳秒”精度或操作系统目录缓存精度)?

添加:对于一些背景信息,这是用于更新某些文件的工具。基本场景是:“如果第一组文件中的某个文件可能比第二组文件中的任何文件更新,则使用第一组文件来更新第二组文件”接下来是“如果第二组文件中的某个文件可能比第三组文件中的任何文件更新,则使用第二组文件来更新第三组文件”。

我遇到的问题是,第一次运行该工具时(修改第一组中的文件后),它将更新第二组文件,然后更新第三组文件(这是正确的行为);但第二次运行该工具时(当没有任何更改时),第二组文件和第三组文件将具有相同的时间戳,因此它必须假设第三组中的文件可能更新,并且它会更新第三组文件无缘无故。

为了解决最初的问题,我在更新第三组文件之前引入了延迟(“nanosleep();”);因此,下次运行该工具时,第三组文件会稍微旧一些。这确实避免了不必要的更新。

当然事情没那么简单——有任意数量的相互依赖的“文件组”(不仅仅是 3 个组)。

这让我想到了我当前的问题 - 对于某些文件系统,时间戳精度高达 2 秒,并且“最坏情况”所需的延迟是巨大的(例如,对于 31 个级别的“”,它总计至少需要 60 秒的延迟)文件组”)。对于大多数文件系统来说,时间戳要精确得多,并且大量浪费的时间可能会消失。当然,该工具的目的是“尽可能便携”,并且我无法真正对时间戳精度做出任何假设(如果我知道文件系统始终是 ext4 或其他系统,那就很容易了) 。

I'm trying to determine the effective precision of the st_mtim.tv_nsec field of struct stat in software, for a specific directory/file system.

Is there a way to do it, that determines the file system's modification time precision (and not the library's "nanosecond" precision, or the OSs directory cache precision)?

ADDED: For some background information, this is for a tool that updates some files. The basic scenario is: "If a file in the first group of files could be newer than any file in the second group of files, then use the first group of files to update the second group of files" followed by "If a file in the second group of files could be newer than any file in the third group of files, then use the second group of files to update the third group of files".

The problem I'm having is that the first time the tool is run (after a file in the first group is modified) it'll update the second group of files and then update the third group of files (which is correct behaviour); but the second time the tool is run (when nothing has been changed) the second group of files and the third group of files will have the same timestamps so it has to assume a file in the third group could be newer and it'll update the third group of files for no reason.

To fix the initial problem I've introduced a delay ("nanosleep();") before updating the third group of files; so that the next time the tool is run the third group of files are slightly older. This does avoid the unnecessary updates.

Of course it's not that simple - there's an arbitrary number of "groups of files" that are inter-dependant (not just 3 groups).

That brings me to my current problem - for some file systems the time stamp precision is as bad as 2 seconds, and the "worst case" delay needed is huge (e.g. it adds up to at least 60 seconds of delays for 31 levels of "groups of files"). For most file systems the time stamps are much more precise, and the large amount of wasted time could disappear. Of course the tool is meant to be "as portable as possible" and I can't really make any assumptions about the time stamp precision (it'd be really easy if I knew the file system was always going to be ext4 or something).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

各自安好 2024-12-03 13:26:36

根据此 OpenGroup 链接

文件系统中文件时间戳的分辨率为
实现定义,但应不低于一秒
解决。三个时间戳的值应始终为
文件系统支持。每当文件的任何时间戳出现时
根据前面的规则设置为值V
本条各款的规定,应立即实施
文件系统支持的最大值的时间戳
不大于V。

所以保证它至少是一秒。

另外,根据 stat(2) 上的 Linux 手册页:

从内核2.5.48开始,stat结构支持纳秒分辨率
对于三个文件时间戳字段。

According to this OpenGroup Link,

The resolution of timestamps of files in a file system is
implementation-defined, but shall be no coarser than one-second
resolution. The three timestamps shall always have values that are
supported by the file system. Whenever any of a file's timestamps are
to be set to a value V according to the rules of the preceding
paragraphs of this section, the implementation shall immediately set
the timestamp to the greatest value supported by the file system that
is not greater than V.

So you are guaranteed it to be at least one-second.

Also, according to this Linux man page on stat(2):

Since kernel 2.5.48, the stat structure supports nanosecond resolution
for the three file timestamp fields.

哽咽笑 2024-12-03 13:26:36

Linux 或 Windows 不是 RTOS(实时操作系统),这种类型的信息可能会延迟 100 毫秒,通常为 +-10 毫秒,因为我记得这是调度程序的标准时间片。

我不是最新的信息,但我很确定它仍然是这样工作的。

编辑

目前nanosleep()的实现是基于正常的
内核定时器机制,其分辨率为 1/HZ s(参见
时间(7))。因此,nanosleep() 总是暂停至少
指定的时间,但是最多可能比指定的时间长 10 毫秒
直到进程再次可运行。出于同样的原因,
*rem 中传递信号时返回的值通常是
四舍五入到下一个较大的 1/HZ 倍数。

来自此处

Linux or Windows are not RTOS (real time operating systems) and that type of information can be off as bad as 100ms, typically +-10ms as I remember that was the standard time slice of the scheduler.

I am not up-to-date with that info, but I am pretty sure this is how it still works.

EDIT

The current implementation of nanosleep() is based on the normal
kernel timer mechanism, which has a resolution of 1/HZ s (see
time(7)). Therefore, nanosleep() pauses always for at least the
specified time, however it can take up to 10 ms longer than specified
until the process becomes runnable again. For the same reason, the
value returned in case of a delivered signal in *rem is usually
rounded to the next larger multiple of 1/HZ s.

From here

相思故 2024-12-03 13:26:36

据我所知,这是不可能的。

唯一实际的解决方法是允许最终用户以适合他们的方式配置它。

注意:我自己尝试找出一种方法,并在此处和其他一些地方询问(主要是 C 和 POSIX 的 IRC 频道);没有人(包括我自己)能够找到一种方法来做到这一点。

As far as I know, it can't be done.

The only practical work-around is to allow the end user to configure it in a way that suits them.

Note: I tried to figure out a way myself, and asked here and a few other places (mostly IRC channels for C and POSIX); and nobody (including myself) have been able to find a way to do it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文