RE: [PATCH v8 12/18] Documentation: flesh out the section in vfs.txt on storing and reporting writeback errors

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Jeff Layton [mailto:jlayton@xxxxxxxxxxxxxxx]
> On Thu, 2017-06-29 at 10:11 -0700, Darrick J. Wong wrote:
> > On Thu, Jun 29, 2017 at 09:19:48AM -0400, jlayton@xxxxxxxxxx wrote:
> > > +Handling errors during writeback
> > > +--------------------------------
> > > +Most applications that utilize the pagecache will periodically call
> > > +fsync to ensure that data written has made it to the backing store.
> >
> > /me wonders if this sentence ought to be worded more strongly, e.g.
> >
> > "Applications that utilize the pagecache must call a data
> > synchronization syscall such as fsync, fdatasync, or msync to ensure
> > that data written has made it to the backing store."
> 
> Well...only if they care about the data. There are some that don't. :)

Also, applications don't "utilize the pagecache"; filesystems use the pagecache.
Applications may or may not use cached I/O.  How about this:

Applications which care about data integrity and use cached I/O will
periodically call fsync(), msync() or fdatasync() to ensure that their
data is durable.

> What should we do about sync_file_range here? It doesn't currently call
> any filesystem operations directly, so we don't have a good way to make
> it selectively use errseq_t handling there.
> 
> I could resurrect the FS_* flag for that, though I don't really like
> that. Should I just go ahead and convert it over to use errseq_t under
> the theory that most callers will eventually want that anyway?

I think so.

��.n��������+%������w��{.n�����{�����jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux