[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v3 04/30] io: fsync before closing a file channel
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC PATCH v3 04/30] io: fsync before closing a file channel |
Date: |
Mon, 15 Jan 2024 09:03:20 +0000 |
User-agent: |
Mutt/2.2.10 (2023-03-25) |
On Mon, Jan 15, 2024 at 04:57:42PM +0800, Peter Xu wrote:
> On Thu, Jan 11, 2024 at 03:46:02PM -0300, Fabiano Rosas wrote:
> > > (2) Why metadata doesn't matter (v.s. fsync(), when CONFIG_FDATASYNC=y)?
> >
> > Syncing the inode information is not critical, it's mostly timestamp
> > information (man inode). And fdatasync makes sure to sync any metadata
> > that would be relevant for the retrieval of the data.
>
> I forgot to reply to this one in the previous reply..
>
> Timestamps look all fine to be old. What about file size? That's also in
> "man inode" as metadata, but I'm not sure whether data will be fully valid
> if e.g. size enlarged but not flushed along with the page caches.
If the size wasn't updated, then syncing of the data would be pointless.
The man page confirms that size is synced:
[quote]
fdatasync() is similar to fsync(), but does not flush modified metadata
unless that metadata is needed in order to allow a subsequent data re‐
trieval to be correctly handled. For example, changes to st_atime or
st_mtime (respectively, time of last access and time of last modifica‐
tion; see inode(7)) do not require flushing because they are not neces‐
sary for a subsequent data read to be handled correctly. On the other
hand, a change to the file size (st_size, as made by say ftruncate(2)),
would require a metadata flush.
[/quote]
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|