9

私はValaでコードを書いていました。そこでは、最初にシステム時刻を取得し、次にファイルを作成し、次にそのファイルのタイムスタンプを取得しました。タイムスタンプは常にシステム時刻よりも早く、500〜1500マイクロ秒の間で意味がありませんでした。

次に、簡単なシェルスクリプトを作成しました。

while true; do
touch ~/tmp/fred.txt
stat ~/tmp/fred.txt|grep ^C
done

次の結果が得られます。

Change: 2013-01-18 16:02:44.290787250 +1100
Change: 2013-01-18 16:02:44.293787250 +1100
Change: 2013-01-18 16:02:44.296787250 +1100
Change: 2013-01-18 16:02:44.298787248 +1100
Change: 2013-01-18 16:02:44.301787248 +1100
Change: 2013-01-18 16:02:44.304787248 +1100
Change: 2013-01-18 16:02:44.306787248 +1100
Change: 2013-01-18 16:02:44.309787248 +1100
Change: 2013-01-18 16:02:44.312787248 +1100
Change: 2013-01-18 16:02:44.315787248 +1100

ご覧のとおり、小数点以下の最初の3桁（ミリ秒）は期待どおりに増加しているので問題ないように見えますが、4桁目以降は正しく表示されません。4桁目から9桁目は、代わりにゆっくりとしたカウントダウンを行っているようです。ext4は最大ナノ秒の精度をサポートしているので、これには何か理由がありますか？アクセスタイムスタンプと変更タイムスタンプは同じように動作します。

4

1 に答える 1

16

inode が拡張時間情報をサポートするのに十分な大きさ (256 バイト以上) である場合、ext4 ファイル システムは格納された時間のナノ秒単位の解像度をサポートします。あなたの場合、2 番目以上の解像度があるため、これは問題ではありません。

内部的には、ext4current_fs_time()の場合は 1ns であるファイル システムのスーパーブロックで指定された時間粒度に切り捨てられた、現在キャッシュされているカーネル時間である ext4 ファイルシステム コード呼び出し。

Linux カーネル内の現在の時刻はキャッシュされ、通常はタイマー割り込みでのみ更新されます。したがって、タイマー割り込みが 10 ミリ秒で実行されている場合、キャッシュされた時間は 10 ミリ秒ごとに 1 回だけ更新されます。更新が発生した場合、結果として得られる時間の精度は、ハードウェアで利用可能なクロック ソースによって異なります。

これを試して、統計呼び出しと同様の結果が得られるかどうかを確認してください。

while true; do date --rfc-3339=ns; done

私のマシン (amd64、intel virtualbox) では、量子化はありません。

例えば

2013-01-18 17:04:21.097211836+11:00
2013-01-18 17:04:21.098354731+11:00
2013-01-18 17:04:21.099282128+11:00
2013-01-18 17:04:21.100276327+11:00
2013-01-18 17:04:21.101348507+11:00
2013-01-18 17:04:21.102516837+11:00

更新：

を使用した上記のチェックdateでは、この状況では実際には何も表示されません。これは、キャッシュされたカーネル時間に基づいて利用可能な最も正確な時間を常に返すシステムコールをdate呼び出すためです。ナノ秒の解像度を提供するために利用可能な場合は、CPU サイクル時間によって調整されます。gettimeofdayただし、ファイル システムに保存されているタイムスタンプは、キャッシュされたカーネル時間のみに基づいています。つまり、最後のタイマー割り込みで計算された時間。

于 2013-01-18T06:06:29.827 に答える