diff for duplicates of <20160426004155.GF18496@dastard> diff --git a/a/1.txt b/N1/1.txt index 2a30f58..d1b20fc 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -128,8 +128,7 @@ Dave. Dave Chinner david@fromorbit.com --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> +_______________________________________________ +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 a64a438..ede935a 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -12,21 +12,21 @@ "Date\0Tue, 26 Apr 2016 10:41:55 +1000\0" "To\0Verma" " Vishal L <vishal.l.verma@intel.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 Mon, Apr 25, 2016 at 11:53:13PM +0000, Verma, Vishal L wrote:\n" @@ -159,10 +159,9 @@ "Dave Chinner\n" "david@fromorbit.com\n" "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + "_______________________________________________\n" + "xfs mailing list\n" + "xfs@oss.sgi.com\n" + http://oss.sgi.com/mailman/listinfo/xfs -d4d17c5ff02ed7f3878323d3450f93da94ee763de658b194039a53fc0e37e49b +339768349a500a78b5f9f1e4274ff9c2da221bfae8c8ce25ff4c7a355a2981c6
diff --git a/a/1.txt b/N2/1.txt index 2a30f58..430c7c4 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,6 +1,6 @@ On Mon, Apr 25, 2016 at 11:53:13PM +0000, Verma, Vishal L wrote: > On Tue, 2016-04-26 at 09:25 +1000, Dave Chinner wrote: -> > +> >� > <> > > > > @@ -28,7 +28,7 @@ they may throw errors. What then? > > > - 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 @@ -56,7 +56,7 @@ situations? > > > - 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 @@ -83,10 +83,10 @@ situations? > > 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 The "figures out" step here is where >95% of the work we'd have to do is. And that's in filesystem and block layer code, not @@ -100,9 +100,9 @@ workable production solution from the filesystem perspective. And AFAICT, it's not even on the roadmap for dm/md layers. > 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 Which is no different to an existing non-DAX application getting an EIO/sigbus from current storage technologies. diff --git a/a/content_digest b/N2/content_digest index a64a438..43d6786 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -31,7 +31,7 @@ "b\0" "On Mon, Apr 25, 2016 at 11:53:13PM +0000, Verma, Vishal L wrote:\n" "> On Tue, 2016-04-26 at 09:25 +1000, Dave Chinner wrote:\n" - "> >\302\240\n" + "> >\303\257\302\277\302\275\n" "> <>\n" "> \n" "> > > \n" @@ -59,7 +59,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\257\302\277\302\275 \303\257\302\277\302\275 * 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" @@ -87,7 +87,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\257\302\277\302\275 \303\257\302\277\302\275 * 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" @@ -114,10 +114,10 @@ "> \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\257\302\277\302\275 - hits badblock\n" + "> \303\257\302\277\302\275 - figures out it is able to recover the data\n" + "> \303\257\302\277\302\275 - handles SIGBUS or EIO\n" + "> \303\257\302\277\302\275 - does a (sector aligned) write() to restore the data\n" "\n" "The \"figures out\" step here is where >95% of the work we'd have to\n" "do is. And that's in filesystem and block layer code, not\n" @@ -131,9 +131,9 @@ "AFAICT, it's not even on the roadmap for dm/md layers.\n" "\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\257\302\277\302\275 - hits badblock\n" + "> \303\257\302\277\302\275 - gets SIGBUS (or EIO) and crashes\n" + "> \303\257\302\277\302\275 - Sysadmin restores file from backup\n" "\n" "Which is no different to an existing non-DAX application getting an\n" "EIO/sigbus from current storage technologies.\n" @@ -165,4 +165,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -d4d17c5ff02ed7f3878323d3450f93da94ee763de658b194039a53fc0e37e49b +ab3922eced6fe6fdc693963595134555662bd8740695cd7c3f94a0b58471e644
diff --git a/a/1.txt b/N3/1.txt index 2a30f58..f7d9add 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -1,6 +1,6 @@ On Mon, Apr 25, 2016 at 11:53:13PM +0000, Verma, Vishal L wrote: > On Tue, 2016-04-26 at 09:25 +1000, Dave Chinner wrote: -> > +> > > <> > > > > @@ -28,7 +28,7 @@ they may throw errors. What then? > > > - 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 @@ -56,7 +56,7 @@ situations? > > > - 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 @@ -83,10 +83,10 @@ situations? > > 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 The "figures out" step here is where >95% of the work we'd have to do is. And that's in filesystem and block layer code, not @@ -100,9 +100,9 @@ workable production solution from the filesystem perspective. And AFAICT, it's not even on the roadmap for dm/md layers. > 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 Which is no different to an existing non-DAX application getting an EIO/sigbus from current storage technologies. diff --git a/a/content_digest b/N3/content_digest index a64a438..6ff0118 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -31,7 +31,7 @@ "b\0" "On Mon, Apr 25, 2016 at 11:53:13PM +0000, Verma, Vishal L wrote:\n" "> On Tue, 2016-04-26 at 09:25 +1000, Dave Chinner wrote:\n" - "> >\302\240\n" + "> > \n" "> <>\n" "> \n" "> > > \n" @@ -59,7 +59,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" + "> > > * 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" @@ -87,7 +87,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" + "> > > * 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" @@ -114,10 +114,10 @@ "> \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" + "> - hits badblock\n" + "> - figures out it is able to recover the data\n" + "> - handles SIGBUS or EIO\n" + "> - does a (sector aligned) write() to restore the data\n" "\n" "The \"figures out\" step here is where >95% of the work we'd have to\n" "do is. And that's in filesystem and block layer code, not\n" @@ -131,9 +131,9 @@ "AFAICT, it's not even on the roadmap for dm/md layers.\n" "\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" + "> - hits badblock\n" + "> - gets SIGBUS (or EIO) and crashes\n" + "> - Sysadmin restores file from backup\n" "\n" "Which is no different to an existing non-DAX application getting an\n" "EIO/sigbus from current storage technologies.\n" @@ -165,4 +165,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -d4d17c5ff02ed7f3878323d3450f93da94ee763de658b194039a53fc0e37e49b +ebec73b06d2a718950400d4ddd5783b4871e6119401a888194f790bdd59d239d
diff --git a/a/1.txt b/N4/1.txt index 2a30f58..082705e 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -127,9 +127,3 @@ Dave. -- Dave Chinner david@fromorbit.com - --- -To unsubscribe, send a message with 'unsubscribe linux-mm' in -the body to majordomo@kvack.org. For more info on Linux MM, -see: http://www.linux-mm.org/ . -Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N4/content_digest index a64a438..7873121 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -157,12 +157,6 @@ "Dave.\n" "-- \n" "Dave Chinner\n" - "david@fromorbit.com\n" - "\n" - "--\n" - "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" - "the body to majordomo@kvack.org. For more info on Linux MM,\n" - "see: http://www.linux-mm.org/ .\n" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + david@fromorbit.com -d4d17c5ff02ed7f3878323d3450f93da94ee763de658b194039a53fc0e37e49b +30c084a82cf41582d6f2a1b58fa2e067ddbeab64e5e971724a982b19fe2b50d3
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.