>fsync() will sync an inode even if only i_atime was changed.I think it was mtime. One doesn't normally call any kind of sync when one is just reading the file. But keeping an accurate mtime is often not worth the I/O. And theoretically, there could be all kinds of "truly meta" metadata that changes as you write to the file but would probably be considered more expendable than the file's actual data. But I think it was always intended that fdatasync() would sync the data in a meaningful way -- i.e. such that the data can be retrieved after a system failure; it surely wasn't meant for the user to understand filesystem internals. I've heard the term "data-related metadata" to distinguish such things as allocation maps and pointer blocks from mtime, permissions, etc. -- Bryan Henderson IBM Almaden Research Center San Jose CA Filesystems - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Linus Torvalds | Linux 2.6.27-rc8 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.20-rc6 |
| Mike Snitzer | Re: Distributed storage. |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Herbert Xu | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state ch... |
