エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
LKML: Jeff Layton: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization
記事へのコメント1件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
LKML: Jeff Layton: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization
[RFC PATCH v1 00/30] fs: inode->i_version rework and optimization tl;dr: I think we can greatly r... [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization tl;dr: I think we can greatly reduce the cost of the inode->i_version counter, by exploiting the fact that we don't need to increment it if no one is looking at it. We can also clean up the code to prepare to eventually expose this value via statx(). The inode->i_version field is supposed to be a value that changes whenever there is
2017/03/08 リンク