diff for duplicates of <1461628381.1421.24.camel@intel.com> diff --git a/a/1.txt b/N1/1.txt index e6962a4..14f83a6 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -88,3 +88,7 @@ Case 2 is handled by patch 4 of the series: > Cheers, > > Dave. +_______________________________________________ +xfs mailing list +xfs@oss.sgi.com +http://oss.sgi.com/mailman/listinfo/xfs diff --git a/a/content_digest b/N1/content_digest index e1b19af..44697c4 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -10,21 +10,21 @@ "Subject\0Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io\0" "Date\0Mon, 25 Apr 2016 23:53:13 +0000\0" "To\0david@fromorbit.com <david@fromorbit.com>\0" - "Cc\0linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>" - linux-block@vger.kernel.org <linux-block@vger.kernel.org> - hch@infradead.org <hch@infradead.org> - xfs@oss.sgi.com <xfs@oss.sgi.com> + "Cc\0hch@infradead.org <hch@infradead.org>" + jack@suse.cz <jack@suse.cz> + axboe@fb.com <axboe@fb.com> linux-nvdimm@ml01.01.org <linux-nvdimm@ml01.01.org> - jmoyer@redhat.com <jmoyer@redhat.com> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + xfs@oss.sgi.com <xfs@oss.sgi.com> + linux-block@vger.kernel.org <linux-block@vger.kernel.org> linux-mm@kvack.org <linux-mm@kvack.org> + jmoyer@redhat.com <jmoyer@redhat.com> viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk> - axboe@fb.com <axboe@fb.com> - akpm@linux-foundation.org <akpm@linux-foundation.org> linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org> + akpm@linux-foundation.org <akpm@linux-foundation.org> linux-ext4@vger.kernel.org <linux-ext4@vger.kernel.org> Wilcox - Matthew R <matthew.r.wilcox@intel.com> - " jack@suse.cz <jack@suse.cz>\0" + " Matthew R <matthew.r.wilcox@intel.com>\0" "\00:1\0" "b\0" "On Tue, 2016-04-26 at 09:25 +1000, Dave Chinner wrote:\n" @@ -116,6 +116,10 @@ "> \n" "> Cheers,\n" "> \n" - > Dave. + "> Dave.\n" + "_______________________________________________\n" + "xfs mailing list\n" + "xfs@oss.sgi.com\n" + http://oss.sgi.com/mailman/listinfo/xfs -eee30de1d708266b97e862886a559d9ecd2527001752081e5e033bf9bfe8f94e +7a5cd58cf4ea8b4862cbd9d0bde1fc072ea3b213d46f9b873ec78da5884bba30
diff --git a/a/1.txt b/N2/1.txt index e6962a4..0588e49 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,5 +1,5 @@ On Tue, 2016-04-26 at 09:25 +1000, Dave Chinner wrote: -> +> <> > > @@ -24,7 +24,7 @@ presumably it knows what files it 'owns', and does a fiemap for those. > > - It write()s those sectors (possibly converted to file offsets > > using > > fiemap) -> > * This triggers the fallback path, but if the application is +> >   * This triggers the fallback path, but if the application is > > doing > > this level of recovery, it will know the sector is bad, and write > > the @@ -41,7 +41,7 @@ option is to restore files from a backup/mirror. > > > > - Or it replaces the entire file from backup also using write() (not > > mmap+stores) -> > * This just frees the fs block, and the next time the block is +> >   * This just frees the fs block, and the next time the block is > > reallocated by the fs, it will likely be zeroed first, and that will > > be > > done through the driver and will clear errors @@ -68,23 +68,23 @@ delete the file, replace with a known good copy, restart application). To summarize, the two cases we want to handle are: 1. Application has inbuilt recovery: - - hits badblock - - figures out it is able to recover the data - - handles SIGBUS or EIO - - does a (sector aligned) write() to restore the data + - hits badblock + - figures out it is able to recover the data + - handles SIGBUS or EIO + - does a (sector aligned) write() to restore the data 2. Application doesn't have any inbuilt recovery mechanism - - hits badblock - - gets SIGBUS (or EIO) and crashes - - Sysadmin restores file from backup + - hits badblock + - gets SIGBUS (or EIO) and crashes + - Sysadmin restores file from backup Case 1 is handled by either a fallback to direct_IO from dax_do_io, or always _actually_ doing direct_IO when we're opened with O_DIRECT in spite of dax (what Dan suggested). Currently if we're mounted with dax, all IO O_DIRECT or otherwise will go through dax_do_io. Case 2 is handled by patch 4 of the series: - dax: use sb_issue_zerout instead of calling dax_clear_sectors +  dax: use sb_issue_zerout instead of calling dax_clear_sectors > > Cheers, > -> Dave. +> Dave.N‹§²æìr¸›zǧu©ž²Æ {\b†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ diff --git a/a/content_digest b/N2/content_digest index e1b19af..f6e8264 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -28,7 +28,7 @@ "\00:1\0" "b\0" "On Tue, 2016-04-26 at 09:25 +1000, Dave Chinner wrote:\n" - ">\302\240\n" + ">\303\202\302\240\n" "<>\n" "\n" "> > \n" @@ -53,7 +53,7 @@ "> > - It write()s those sectors (possibly converted to file offsets\n" "> > using\n" "> > fiemap)\n" - "> > \302\240 \302\240 * This triggers the fallback path, but if the application is\n" + "> > \303\202\302\240 \303\202\302\240 * This triggers the fallback path, but if the application is\n" "> > doing\n" "> > this level of recovery, it will know the sector is bad, and write\n" "> > the\n" @@ -70,7 +70,7 @@ "> > \n" "> > - Or it replaces the entire file from backup also using write() (not\n" "> > mmap+stores)\n" - "> > \302\240 \302\240 * This just frees the fs block, and the next time the block is\n" + "> > \303\202\302\240 \303\202\302\240 * This just frees the fs block, and the next time the block is\n" "> > reallocated by the fs, it will likely be zeroed first, and that will\n" "> > be\n" "> > done through the driver and will clear errors\n" @@ -97,25 +97,25 @@ "\n" "To summarize, the two cases we want to handle are:\n" "1. Application has inbuilt recovery:\n" - "\302\240 - hits badblock\n" - "\302\240 - figures out it is able to recover the data\n" - "\302\240 - handles SIGBUS or EIO\n" - "\302\240 - does a (sector aligned) write() to restore the data\n" + "\303\202\302\240 - hits badblock\n" + "\303\202\302\240 - figures out it is able to recover the data\n" + "\303\202\302\240 - handles SIGBUS or EIO\n" + "\303\202\302\240 - does a (sector aligned) write() to restore the data\n" "2. Application doesn't have any inbuilt recovery mechanism\n" - "\302\240 - hits badblock\n" - "\302\240 - gets SIGBUS (or EIO) and crashes\n" - "\302\240 - Sysadmin restores file from backup\n" + "\303\202\302\240 - hits badblock\n" + "\303\202\302\240 - gets SIGBUS (or EIO) and crashes\n" + "\303\202\302\240 - Sysadmin restores file from backup\n" "\n" "Case 1 is handled by either a fallback to direct_IO from dax_do_io, or\n" "always _actually_ doing direct_IO when we're opened with O_DIRECT in\n" "spite of dax (what Dan suggested). Currently if we're mounted with dax,\n" "all IO O_DIRECT or otherwise will go through dax_do_io.\n" "Case 2 is handled by patch 4 of the series:\n" - "\302\240 \302\240 dax: use sb_issue_zerout instead of calling dax_clear_sectors\n" + "\303\202\302\240 \303\202\302\240 dax: use sb_issue_zerout instead of calling dax_clear_sectors\n" "\n" "> \n" "> Cheers,\n" "> \n" - > Dave. + "> Dave.N\302\213\302\247\302\262\303\246\303\254r\302\270\302\233z\303\207\302\247u\302\251\302\236\302\262\303\206\302\240{\b\302\255\302\206\303\251\303\254\302\271\302\273\034\302\256&\303\236\302\226)\303\256\303\206i\302\242\302\236\303\230^n\302\207r\302\266\302\211\302\232\302\216\302\212\303\235\302\242j$\302\275\302\247$\302\242\302\270\005\302\242\302\271\302\250\302\255\303\250\302\247~\302\212'.)\303\256\303\204\303\203,y\303\250m\302\266\302\237\303\277\303\203\f%\302\212{\302\261\302\232j+\302\203\303\260\303\250\302\236\303\227\302\246j)Z\302\206\302\267\302\237" -eee30de1d708266b97e862886a559d9ecd2527001752081e5e033bf9bfe8f94e +9ce917873c919362eac6216e70b9e8df4cf4aae0b0246692e13add48cd9ba8bf
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.