All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <BY2PR21MB003653755FD85FCE2C49393ECBD20@BY2PR21MB0036.namprd21.prod.outlook.com>

diff --git a/a/1.txt b/N1/1.txt
index 827861b..88eaf62 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,27 +1,34 @@
-RnJvbTogSmVmZiBMYXl0b24gW21haWx0bzpqbGF5dG9uQHBvb2NoaWVyZWRzLm5ldF0NCj4gT24g
-VGh1LCAyMDE3LTA2LTI5IGF0IDEwOjExIC0wNzAwLCBEYXJyaWNrIEouIFdvbmcgd3JvdGU6DQo+
-ID4gT24gVGh1LCBKdW4gMjksIDIwMTcgYXQgMDk6MTk6NDhBTSAtMDQwMCwgamxheXRvbkBrZXJu
-ZWwub3JnIHdyb3RlOg0KPiA+ID4gK0hhbmRsaW5nIGVycm9ycyBkdXJpbmcgd3JpdGViYWNrDQo+
-ID4gPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ICtNb3N0IGFwcGxp
-Y2F0aW9ucyB0aGF0IHV0aWxpemUgdGhlIHBhZ2VjYWNoZSB3aWxsIHBlcmlvZGljYWxseSBjYWxs
-DQo+ID4gPiArZnN5bmMgdG8gZW5zdXJlIHRoYXQgZGF0YSB3cml0dGVuIGhhcyBtYWRlIGl0IHRv
-IHRoZSBiYWNraW5nIHN0b3JlLg0KPiA+DQo+ID4gL21lIHdvbmRlcnMgaWYgdGhpcyBzZW50ZW5j
-ZSBvdWdodCB0byBiZSB3b3JkZWQgbW9yZSBzdHJvbmdseSwgZS5nLg0KPiA+DQo+ID4gIkFwcGxp
-Y2F0aW9ucyB0aGF0IHV0aWxpemUgdGhlIHBhZ2VjYWNoZSBtdXN0IGNhbGwgYSBkYXRhDQo+ID4g
-c3luY2hyb25pemF0aW9uIHN5c2NhbGwgc3VjaCBhcyBmc3luYywgZmRhdGFzeW5jLCBvciBtc3lu
-YyB0byBlbnN1cmUNCj4gPiB0aGF0IGRhdGEgd3JpdHRlbiBoYXMgbWFkZSBpdCB0byB0aGUgYmFj
-a2luZyBzdG9yZS4iDQo+IA0KPiBXZWxsLi4ub25seSBpZiB0aGV5IGNhcmUgYWJvdXQgdGhlIGRh
-dGEuIFRoZXJlIGFyZSBzb21lIHRoYXQgZG9uJ3QuIDopDQoNCkFsc28sIGFwcGxpY2F0aW9ucyBk
-b24ndCAidXRpbGl6ZSB0aGUgcGFnZWNhY2hlIjsgZmlsZXN5c3RlbXMgdXNlIHRoZSBwYWdlY2Fj
-aGUuDQpBcHBsaWNhdGlvbnMgbWF5IG9yIG1heSBub3QgdXNlIGNhY2hlZCBJL08uICBIb3cgYWJv
-dXQgdGhpczoNCg0KQXBwbGljYXRpb25zIHdoaWNoIGNhcmUgYWJvdXQgZGF0YSBpbnRlZ3JpdHkg
-YW5kIHVzZSBjYWNoZWQgSS9PIHdpbGwNCnBlcmlvZGljYWxseSBjYWxsIGZzeW5jKCksIG1zeW5j
-KCkgb3IgZmRhdGFzeW5jKCkgdG8gZW5zdXJlIHRoYXQgdGhlaXINCmRhdGEgaXMgZHVyYWJsZS4N
-Cg0KPiBXaGF0IHNob3VsZCB3ZSBkbyBhYm91dCBzeW5jX2ZpbGVfcmFuZ2UgaGVyZT8gSXQgZG9l
-c24ndCBjdXJyZW50bHkgY2FsbA0KPiBhbnkgZmlsZXN5c3RlbSBvcGVyYXRpb25zIGRpcmVjdGx5
-LCBzbyB3ZSBkb24ndCBoYXZlIGEgZ29vZCB3YXkgdG8gbWFrZQ0KPiBpdCBzZWxlY3RpdmVseSB1
-c2UgZXJyc2VxX3QgaGFuZGxpbmcgdGhlcmUuDQo+IA0KPiBJIGNvdWxkIHJlc3VycmVjdCB0aGUg
-RlNfKiBmbGFnIGZvciB0aGF0LCB0aG91Z2ggSSBkb24ndCByZWFsbHkgbGlrZQ0KPiB0aGF0LiBT
-aG91bGQgSSBqdXN0IGdvIGFoZWFkIGFuZCBjb252ZXJ0IGl0IG92ZXIgdG8gdXNlIGVycnNlcV90
-IHVuZGVyDQo+IHRoZSB0aGVvcnkgdGhhdCBtb3N0IGNhbGxlcnMgd2lsbCBldmVudHVhbGx5IHdh
-bnQgdGhhdCBhbnl3YXk/DQoNCkkgdGhpbmsgc28uDQoNCg==
\ No newline at end of file
+From: Jeff Layton [mailto:jlayton@poochiereds.net]
+> On Thu, 2017-06-29 at 10:11 -0700, Darrick J. Wong wrote:
+> > On Thu, Jun 29, 2017 at 09:19:48AM -0400, jlayton@kernel.org 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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index a0c709c..4a5de30 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -54,33 +54,40 @@
   "b\0"
 ]
 [
-  "RnJvbTogSmVmZiBMYXl0b24gW21haWx0bzpqbGF5dG9uQHBvb2NoaWVyZWRzLm5ldF0NCj4gT24g\n",
-  "VGh1LCAyMDE3LTA2LTI5IGF0IDEwOjExIC0wNzAwLCBEYXJyaWNrIEouIFdvbmcgd3JvdGU6DQo+\n",
-  "ID4gT24gVGh1LCBKdW4gMjksIDIwMTcgYXQgMDk6MTk6NDhBTSAtMDQwMCwgamxheXRvbkBrZXJu\n",
-  "ZWwub3JnIHdyb3RlOg0KPiA+ID4gK0hhbmRsaW5nIGVycm9ycyBkdXJpbmcgd3JpdGViYWNrDQo+\n",
-  "ID4gPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ICtNb3N0IGFwcGxp\n",
-  "Y2F0aW9ucyB0aGF0IHV0aWxpemUgdGhlIHBhZ2VjYWNoZSB3aWxsIHBlcmlvZGljYWxseSBjYWxs\n",
-  "DQo+ID4gPiArZnN5bmMgdG8gZW5zdXJlIHRoYXQgZGF0YSB3cml0dGVuIGhhcyBtYWRlIGl0IHRv\n",
-  "IHRoZSBiYWNraW5nIHN0b3JlLg0KPiA+DQo+ID4gL21lIHdvbmRlcnMgaWYgdGhpcyBzZW50ZW5j\n",
-  "ZSBvdWdodCB0byBiZSB3b3JkZWQgbW9yZSBzdHJvbmdseSwgZS5nLg0KPiA+DQo+ID4gIkFwcGxp\n",
-  "Y2F0aW9ucyB0aGF0IHV0aWxpemUgdGhlIHBhZ2VjYWNoZSBtdXN0IGNhbGwgYSBkYXRhDQo+ID4g\n",
-  "c3luY2hyb25pemF0aW9uIHN5c2NhbGwgc3VjaCBhcyBmc3luYywgZmRhdGFzeW5jLCBvciBtc3lu\n",
-  "YyB0byBlbnN1cmUNCj4gPiB0aGF0IGRhdGEgd3JpdHRlbiBoYXMgbWFkZSBpdCB0byB0aGUgYmFj\n",
-  "a2luZyBzdG9yZS4iDQo+IA0KPiBXZWxsLi4ub25seSBpZiB0aGV5IGNhcmUgYWJvdXQgdGhlIGRh\n",
-  "dGEuIFRoZXJlIGFyZSBzb21lIHRoYXQgZG9uJ3QuIDopDQoNCkFsc28sIGFwcGxpY2F0aW9ucyBk\n",
-  "b24ndCAidXRpbGl6ZSB0aGUgcGFnZWNhY2hlIjsgZmlsZXN5c3RlbXMgdXNlIHRoZSBwYWdlY2Fj\n",
-  "aGUuDQpBcHBsaWNhdGlvbnMgbWF5IG9yIG1heSBub3QgdXNlIGNhY2hlZCBJL08uICBIb3cgYWJv\n",
-  "dXQgdGhpczoNCg0KQXBwbGljYXRpb25zIHdoaWNoIGNhcmUgYWJvdXQgZGF0YSBpbnRlZ3JpdHkg\n",
-  "YW5kIHVzZSBjYWNoZWQgSS9PIHdpbGwNCnBlcmlvZGljYWxseSBjYWxsIGZzeW5jKCksIG1zeW5j\n",
-  "KCkgb3IgZmRhdGFzeW5jKCkgdG8gZW5zdXJlIHRoYXQgdGhlaXINCmRhdGEgaXMgZHVyYWJsZS4N\n",
-  "Cg0KPiBXaGF0IHNob3VsZCB3ZSBkbyBhYm91dCBzeW5jX2ZpbGVfcmFuZ2UgaGVyZT8gSXQgZG9l\n",
-  "c24ndCBjdXJyZW50bHkgY2FsbA0KPiBhbnkgZmlsZXN5c3RlbSBvcGVyYXRpb25zIGRpcmVjdGx5\n",
-  "LCBzbyB3ZSBkb24ndCBoYXZlIGEgZ29vZCB3YXkgdG8gbWFrZQ0KPiBpdCBzZWxlY3RpdmVseSB1\n",
-  "c2UgZXJyc2VxX3QgaGFuZGxpbmcgdGhlcmUuDQo+IA0KPiBJIGNvdWxkIHJlc3VycmVjdCB0aGUg\n",
-  "RlNfKiBmbGFnIGZvciB0aGF0LCB0aG91Z2ggSSBkb24ndCByZWFsbHkgbGlrZQ0KPiB0aGF0LiBT\n",
-  "aG91bGQgSSBqdXN0IGdvIGFoZWFkIGFuZCBjb252ZXJ0IGl0IG92ZXIgdG8gdXNlIGVycnNlcV90\n",
-  "IHVuZGVyDQo+IHRoZSB0aGVvcnkgdGhhdCBtb3N0IGNhbGxlcnMgd2lsbCBldmVudHVhbGx5IHdh\n",
-  "bnQgdGhhdCBhbnl3YXk/DQoNCkkgdGhpbmsgc28uDQoNCg=="
+  "From: Jeff Layton [mailto:jlayton\@poochiereds.net]\n",
+  "> On Thu, 2017-06-29 at 10:11 -0700, Darrick J. Wong wrote:\n",
+  "> > On Thu, Jun 29, 2017 at 09:19:48AM -0400, jlayton\@kernel.org wrote:\n",
+  "> > > +Handling errors during writeback\n",
+  "> > > +--------------------------------\n",
+  "> > > +Most applications that utilize the pagecache will periodically call\n",
+  "> > > +fsync to ensure that data written has made it to the backing store.\n",
+  "> >\n",
+  "> > /me wonders if this sentence ought to be worded more strongly, e.g.\n",
+  "> >\n",
+  "> > \"Applications that utilize the pagecache must call a data\n",
+  "> > synchronization syscall such as fsync, fdatasync, or msync to ensure\n",
+  "> > that data written has made it to the backing store.\"\n",
+  "> \n",
+  "> Well...only if they care about the data. There are some that don't. :)\n",
+  "\n",
+  "Also, applications don't \"utilize the pagecache\"; filesystems use the pagecache.\n",
+  "Applications may or may not use cached I/O.  How about this:\n",
+  "\n",
+  "Applications which care about data integrity and use cached I/O will\n",
+  "periodically call fsync(), msync() or fdatasync() to ensure that their\n",
+  "data is durable.\n",
+  "\n",
+  "> What should we do about sync_file_range here? It doesn't currently call\n",
+  "> any filesystem operations directly, so we don't have a good way to make\n",
+  "> it selectively use errseq_t handling there.\n",
+  "> \n",
+  "> I could resurrect the FS_* flag for that, though I don't really like\n",
+  "> that. Should I just go ahead and convert it over to use errseq_t under\n",
+  "> the theory that most callers will eventually want that anyway?\n",
+  "\n",
+  "I think so.\n",
+  "\n",
+  "\303\277\303\264\303\250\302\272{.n\303\207+\302\211\302\267\302\237\302\256\302\211\302\255\302\206+%\302\212\303\213\303\277\302\261\303\251\303\235\302\266\27\302\245\302\212w\303\277\302\272{.n\303\207+\302\211\302\267\302\245\302\212{\302\261\303\275\302\273k~\303\217\303\242\302\236\303\230^n\302\207r\302\241\303\266\302\246z\303\213\32\302\201\303\253h\302\231\302\250\303\250\302\255\303\232&\302\243\303\273\303\240z\302\277\303\244z\302\271\303\236\302\227\303\272+\302\200\303\212+zf\302\243\302\242\302\267h\302\232\302\210\302\247~\302\206\302\255\302\206\303\233i\303\277\303\277\303\257\302\201\303\252\303\277\302\221\303\252\303\247z_\303\250\302\256\17\303\246j:+v\302\211\302\250\303\276)\303\237\302\243\303\270m"
 ]
 
-f681124c19c9a095817b24fa13b4a515256d8b35c424a9a95e320a4c33c479c6
+cd786d4f82a4e63b93dd808e8a68063a73e59bcaf4c6df4f4ad8530011fe0186

diff --git a/a/1.txt b/N2/1.txt
index 827861b..c59ef52 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,27 +1,32 @@
-RnJvbTogSmVmZiBMYXl0b24gW21haWx0bzpqbGF5dG9uQHBvb2NoaWVyZWRzLm5ldF0NCj4gT24g
-VGh1LCAyMDE3LTA2LTI5IGF0IDEwOjExIC0wNzAwLCBEYXJyaWNrIEouIFdvbmcgd3JvdGU6DQo+
-ID4gT24gVGh1LCBKdW4gMjksIDIwMTcgYXQgMDk6MTk6NDhBTSAtMDQwMCwgamxheXRvbkBrZXJu
-ZWwub3JnIHdyb3RlOg0KPiA+ID4gK0hhbmRsaW5nIGVycm9ycyBkdXJpbmcgd3JpdGViYWNrDQo+
-ID4gPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ICtNb3N0IGFwcGxp
-Y2F0aW9ucyB0aGF0IHV0aWxpemUgdGhlIHBhZ2VjYWNoZSB3aWxsIHBlcmlvZGljYWxseSBjYWxs
-DQo+ID4gPiArZnN5bmMgdG8gZW5zdXJlIHRoYXQgZGF0YSB3cml0dGVuIGhhcyBtYWRlIGl0IHRv
-IHRoZSBiYWNraW5nIHN0b3JlLg0KPiA+DQo+ID4gL21lIHdvbmRlcnMgaWYgdGhpcyBzZW50ZW5j
-ZSBvdWdodCB0byBiZSB3b3JkZWQgbW9yZSBzdHJvbmdseSwgZS5nLg0KPiA+DQo+ID4gIkFwcGxp
-Y2F0aW9ucyB0aGF0IHV0aWxpemUgdGhlIHBhZ2VjYWNoZSBtdXN0IGNhbGwgYSBkYXRhDQo+ID4g
-c3luY2hyb25pemF0aW9uIHN5c2NhbGwgc3VjaCBhcyBmc3luYywgZmRhdGFzeW5jLCBvciBtc3lu
-YyB0byBlbnN1cmUNCj4gPiB0aGF0IGRhdGEgd3JpdHRlbiBoYXMgbWFkZSBpdCB0byB0aGUgYmFj
-a2luZyBzdG9yZS4iDQo+IA0KPiBXZWxsLi4ub25seSBpZiB0aGV5IGNhcmUgYWJvdXQgdGhlIGRh
-dGEuIFRoZXJlIGFyZSBzb21lIHRoYXQgZG9uJ3QuIDopDQoNCkFsc28sIGFwcGxpY2F0aW9ucyBk
-b24ndCAidXRpbGl6ZSB0aGUgcGFnZWNhY2hlIjsgZmlsZXN5c3RlbXMgdXNlIHRoZSBwYWdlY2Fj
-aGUuDQpBcHBsaWNhdGlvbnMgbWF5IG9yIG1heSBub3QgdXNlIGNhY2hlZCBJL08uICBIb3cgYWJv
-dXQgdGhpczoNCg0KQXBwbGljYXRpb25zIHdoaWNoIGNhcmUgYWJvdXQgZGF0YSBpbnRlZ3JpdHkg
-YW5kIHVzZSBjYWNoZWQgSS9PIHdpbGwNCnBlcmlvZGljYWxseSBjYWxsIGZzeW5jKCksIG1zeW5j
-KCkgb3IgZmRhdGFzeW5jKCkgdG8gZW5zdXJlIHRoYXQgdGhlaXINCmRhdGEgaXMgZHVyYWJsZS4N
-Cg0KPiBXaGF0IHNob3VsZCB3ZSBkbyBhYm91dCBzeW5jX2ZpbGVfcmFuZ2UgaGVyZT8gSXQgZG9l
-c24ndCBjdXJyZW50bHkgY2FsbA0KPiBhbnkgZmlsZXN5c3RlbSBvcGVyYXRpb25zIGRpcmVjdGx5
-LCBzbyB3ZSBkb24ndCBoYXZlIGEgZ29vZCB3YXkgdG8gbWFrZQ0KPiBpdCBzZWxlY3RpdmVseSB1
-c2UgZXJyc2VxX3QgaGFuZGxpbmcgdGhlcmUuDQo+IA0KPiBJIGNvdWxkIHJlc3VycmVjdCB0aGUg
-RlNfKiBmbGFnIGZvciB0aGF0LCB0aG91Z2ggSSBkb24ndCByZWFsbHkgbGlrZQ0KPiB0aGF0LiBT
-aG91bGQgSSBqdXN0IGdvIGFoZWFkIGFuZCBjb252ZXJ0IGl0IG92ZXIgdG8gdXNlIGVycnNlcV90
-IHVuZGVyDQo+IHRoZSB0aGVvcnkgdGhhdCBtb3N0IGNhbGxlcnMgd2lsbCBldmVudHVhbGx5IHdh
-bnQgdGhhdCBhbnl3YXk/DQoNCkkgdGhpbmsgc28uDQoNCg==
\ No newline at end of file
+From: Jeff Layton [mailto:jlayton@poochiereds.net]
+> On Thu, 2017-06-29 at 10:11 -0700, Darrick J. Wong wrote:
+> > On Thu, Jun 29, 2017 at 09:19:48AM -0400, jlayton@kernel.org 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.
\ No newline at end of file
diff --git a/a/content_digest b/N2/content_digest
index a0c709c..d77a25b 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -54,33 +54,38 @@
   "b\0"
 ]
 [
-  "RnJvbTogSmVmZiBMYXl0b24gW21haWx0bzpqbGF5dG9uQHBvb2NoaWVyZWRzLm5ldF0NCj4gT24g\n",
-  "VGh1LCAyMDE3LTA2LTI5IGF0IDEwOjExIC0wNzAwLCBEYXJyaWNrIEouIFdvbmcgd3JvdGU6DQo+\n",
-  "ID4gT24gVGh1LCBKdW4gMjksIDIwMTcgYXQgMDk6MTk6NDhBTSAtMDQwMCwgamxheXRvbkBrZXJu\n",
-  "ZWwub3JnIHdyb3RlOg0KPiA+ID4gK0hhbmRsaW5nIGVycm9ycyBkdXJpbmcgd3JpdGViYWNrDQo+\n",
-  "ID4gPiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ICtNb3N0IGFwcGxp\n",
-  "Y2F0aW9ucyB0aGF0IHV0aWxpemUgdGhlIHBhZ2VjYWNoZSB3aWxsIHBlcmlvZGljYWxseSBjYWxs\n",
-  "DQo+ID4gPiArZnN5bmMgdG8gZW5zdXJlIHRoYXQgZGF0YSB3cml0dGVuIGhhcyBtYWRlIGl0IHRv\n",
-  "IHRoZSBiYWNraW5nIHN0b3JlLg0KPiA+DQo+ID4gL21lIHdvbmRlcnMgaWYgdGhpcyBzZW50ZW5j\n",
-  "ZSBvdWdodCB0byBiZSB3b3JkZWQgbW9yZSBzdHJvbmdseSwgZS5nLg0KPiA+DQo+ID4gIkFwcGxp\n",
-  "Y2F0aW9ucyB0aGF0IHV0aWxpemUgdGhlIHBhZ2VjYWNoZSBtdXN0IGNhbGwgYSBkYXRhDQo+ID4g\n",
-  "c3luY2hyb25pemF0aW9uIHN5c2NhbGwgc3VjaCBhcyBmc3luYywgZmRhdGFzeW5jLCBvciBtc3lu\n",
-  "YyB0byBlbnN1cmUNCj4gPiB0aGF0IGRhdGEgd3JpdHRlbiBoYXMgbWFkZSBpdCB0byB0aGUgYmFj\n",
-  "a2luZyBzdG9yZS4iDQo+IA0KPiBXZWxsLi4ub25seSBpZiB0aGV5IGNhcmUgYWJvdXQgdGhlIGRh\n",
-  "dGEuIFRoZXJlIGFyZSBzb21lIHRoYXQgZG9uJ3QuIDopDQoNCkFsc28sIGFwcGxpY2F0aW9ucyBk\n",
-  "b24ndCAidXRpbGl6ZSB0aGUgcGFnZWNhY2hlIjsgZmlsZXN5c3RlbXMgdXNlIHRoZSBwYWdlY2Fj\n",
-  "aGUuDQpBcHBsaWNhdGlvbnMgbWF5IG9yIG1heSBub3QgdXNlIGNhY2hlZCBJL08uICBIb3cgYWJv\n",
-  "dXQgdGhpczoNCg0KQXBwbGljYXRpb25zIHdoaWNoIGNhcmUgYWJvdXQgZGF0YSBpbnRlZ3JpdHkg\n",
-  "YW5kIHVzZSBjYWNoZWQgSS9PIHdpbGwNCnBlcmlvZGljYWxseSBjYWxsIGZzeW5jKCksIG1zeW5j\n",
-  "KCkgb3IgZmRhdGFzeW5jKCkgdG8gZW5zdXJlIHRoYXQgdGhlaXINCmRhdGEgaXMgZHVyYWJsZS4N\n",
-  "Cg0KPiBXaGF0IHNob3VsZCB3ZSBkbyBhYm91dCBzeW5jX2ZpbGVfcmFuZ2UgaGVyZT8gSXQgZG9l\n",
-  "c24ndCBjdXJyZW50bHkgY2FsbA0KPiBhbnkgZmlsZXN5c3RlbSBvcGVyYXRpb25zIGRpcmVjdGx5\n",
-  "LCBzbyB3ZSBkb24ndCBoYXZlIGEgZ29vZCB3YXkgdG8gbWFrZQ0KPiBpdCBzZWxlY3RpdmVseSB1\n",
-  "c2UgZXJyc2VxX3QgaGFuZGxpbmcgdGhlcmUuDQo+IA0KPiBJIGNvdWxkIHJlc3VycmVjdCB0aGUg\n",
-  "RlNfKiBmbGFnIGZvciB0aGF0LCB0aG91Z2ggSSBkb24ndCByZWFsbHkgbGlrZQ0KPiB0aGF0LiBT\n",
-  "aG91bGQgSSBqdXN0IGdvIGFoZWFkIGFuZCBjb252ZXJ0IGl0IG92ZXIgdG8gdXNlIGVycnNlcV90\n",
-  "IHVuZGVyDQo+IHRoZSB0aGVvcnkgdGhhdCBtb3N0IGNhbGxlcnMgd2lsbCBldmVudHVhbGx5IHdh\n",
-  "bnQgdGhhdCBhbnl3YXk/DQoNCkkgdGhpbmsgc28uDQoNCg=="
+  "From: Jeff Layton [mailto:jlayton\@poochiereds.net]\n",
+  "> On Thu, 2017-06-29 at 10:11 -0700, Darrick J. Wong wrote:\n",
+  "> > On Thu, Jun 29, 2017 at 09:19:48AM -0400, jlayton\@kernel.org wrote:\n",
+  "> > > +Handling errors during writeback\n",
+  "> > > +--------------------------------\n",
+  "> > > +Most applications that utilize the pagecache will periodically call\n",
+  "> > > +fsync to ensure that data written has made it to the backing store.\n",
+  "> >\n",
+  "> > /me wonders if this sentence ought to be worded more strongly, e.g.\n",
+  "> >\n",
+  "> > \"Applications that utilize the pagecache must call a data\n",
+  "> > synchronization syscall such as fsync, fdatasync, or msync to ensure\n",
+  "> > that data written has made it to the backing store.\"\n",
+  "> \n",
+  "> Well...only if they care about the data. There are some that don't. :)\n",
+  "\n",
+  "Also, applications don't \"utilize the pagecache\"; filesystems use the pagecache.\n",
+  "Applications may or may not use cached I/O.  How about this:\n",
+  "\n",
+  "Applications which care about data integrity and use cached I/O will\n",
+  "periodically call fsync(), msync() or fdatasync() to ensure that their\n",
+  "data is durable.\n",
+  "\n",
+  "> What should we do about sync_file_range here? It doesn't currently call\n",
+  "> any filesystem operations directly, so we don't have a good way to make\n",
+  "> it selectively use errseq_t handling there.\n",
+  "> \n",
+  "> I could resurrect the FS_* flag for that, though I don't really like\n",
+  "> that. Should I just go ahead and convert it over to use errseq_t under\n",
+  "> the theory that most callers will eventually want that anyway?\n",
+  "\n",
+  "I think so."
 ]
 
-f681124c19c9a095817b24fa13b4a515256d8b35c424a9a95e320a4c33c479c6
+f88428a92d33d612be5e447901efc0a39033c9f8a772298829fec5c917d2c594

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.