Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Mon, 21 Jun 1999 12:03:00 +0100 (BST) | Subject | Re: [patch] `cp /dev/zero /tmp' (patch against 2.2.9) |
| |
Hi,
On Sun, 20 Jun 1999 15:45:02 +0200 (CEST), Andrea Arcangeli <andrea@suse.de> said:
> I think the major issue with fsync is having to read from disk in order to > complete the operation. The fact that we don't have to lookup the buffer > cache anymore to check if there's a dirty buffer in memory will sure cut > down the complexity of the operation, but according to me the real issue > is to avoid read-I/O from disk (think if you have only one block dirty in > the metadata (after an append of data to an inode), in such case you don't > want to generate lots of read-I/O just to write 1k to disk).
> fdatasync instead is just _fine_ in this regard.
No it isn't. fdatasync has exactly the same requirements here as fsync. The only things which fdatasync is allowed to skip are the inode timestamps; all other inode and metadata modifications must still be synced.
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |