> These change still have the undesirable property that although the > modified pages may be flushed to stable storage, the metadata on > the file will not be updated until the application takes positive > action. This is permissible given the current wording in the > specifications, but it would be much more desirable if sync(2), > fsync(P), or the inode being written out due to normal system > activity would also cause the metadata to be updated. > > Perhaps the setting of the flag could be checked in some places > like __sync_single_inode() and do_fsync()? I don't see the point in updating the timestamp from these functions. The file isn't _modified_ by sync() or fsync(). Just as it's not modified by stat(). sync() and fsync() do cache->disk, while the file itself stays the same. OTOH msync(MS_ASYNC) does memory->file, which is a conceptually file modifying operation. OK, msync(MS_ASYNC) is actually a no-op on 2.6.18+, but that's purely an implementation detail and no application should be relying on it. Before 2.6.18 sync() or fsync() acually didn't flush data written through a shared mapping to disk, only msync(MS_SYNC), because the dirty state was only available in the page tables, not in the page or the inode. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
