qemu-devel
[Top][All Lists]
Advanced

[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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]