diff for duplicates of <1461682731.26226.20.camel@kernel.org> diff --git a/a/1.txt b/N1/1.txt index 6dd9b01..25d4104 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -119,8 +119,7 @@ with DAX. > > Dave. --- -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 cba8051..f5a14bb 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -14,14 +14,14 @@ "To\0Dave Chinner <david@fromorbit.com>" Verma " Vishal L <vishal.l.verma@intel.com>\0" - "Cc\0hch@infradead.org <hch@infradead.org>" + "Cc\0axboe@fb.com <axboe@fb.com>" jack@suse.cz <jack@suse.cz> - axboe@fb.com <axboe@fb.com> linux-nvdimm@ml01.01.org <linux-nvdimm@ml01.01.org> 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> + hch@infradead.org <hch@infradead.org> linux-mm@kvack.org <linux-mm@kvack.org> + linux-block@vger.kernel.org <linux-block@vger.kernel.org> viro@zeniv.linux.org.uk <viro@zeniv.linux.org.uk> linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org> akpm@linux-foundation.org <akpm@linux-foundation.org> @@ -151,10 +151,9 @@ "> \n" "> Dave.\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 -455d0c8945f4ffc980c9c28eb0368e9a15387f5923701dfa90469b261fee71e3 +1cf9cdeef7939a61bb859ac5f5f021e143cf3cddf2f6a07918b5dc46651500cd
diff --git a/a/1.txt b/N2/1.txt index 6dd9b01..0b9ee11 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -5,14 +5,14 @@ On Tue, 2016-04-26 at 10:41 +1000, Dave Chinner wrote: > > presumably it knows what files it 'owns', and does a fiemap for > > those. > You're assuming that only the DAX aware application accesses it's -> files. users, backup programs, data replicators, fileystem -> re-organisers (e.g. defragmenters) etc all may access the files and +> files.A A users, backup programs, data replicators, fileystem +> re-organisers (e.g.A A defragmenters) etc all may access the files and > they may throw errors. What then? In this scenario, backup applications etc that try to read that data before it has been replaced will just hit the errors and fail.. -> +>A <> @@ -46,17 +46,17 @@ another if the app wants to try something fancy for recovery. <> > -> > +> >A > > 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 +> > A - hits badblock +> > A - figures out it is able to recover the data +> > A - handles SIGBUS or EIO +> > A - 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 > userspace, and userspace can't do that work in a signal handler. -> And it can still fall down to the second case when the application +> And itA A can still fall down to the second case when the application > doesn't have another copy of the data somewhere. Ah when I said "figures out" I was only thinking if the application has @@ -71,16 +71,16 @@ additional recovery mechanisms at the block/fs layer. > > > > > 2. Application doesn't have any inbuilt recovery mechanism -> > - hits badblock -> > - gets SIGBUS (or EIO) and crashes -> > - Sysadmin restores file from backup +> > A - hits badblock +> > A - gets SIGBUS (or EIO) and crashes +> > A - Sysadmin restores file from backup > Which is no different to an existing non-DAX application getting an > EIO/sigbus from current storage technologies. > > Except: in the existing storage stack, redundancy and correction has > already had to have failed for the application to see such an error. > Hence this is normally considered a DR case as there's had to be -> cascading failures (e.g. multiple disk failures in a RAID) to get +> cascading failures (e.g.A A multiple disk failures in a RAID) to get > to this stage, not a single error in a single sector in > non-redundant storage. > diff --git a/a/content_digest b/N2/content_digest index cba8051..aa15858 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -37,14 +37,14 @@ "> > presumably it knows what files it 'owns', and does a fiemap for\n" "> > those.\n" "> You're assuming that only the DAX aware application accesses it's\n" - "> files.\302\240\302\240users, backup programs, data replicators, fileystem\n" - "> re-organisers (e.g.\302\240\302\240defragmenters) etc all may access the files and\n" + "> files.A A users, backup programs, data replicators, fileystem\n" + "> re-organisers (e.g.A A defragmenters) etc all may access the files and\n" "> they may throw errors. What then?\n" "\n" "In this scenario, backup applications etc that try to read that data\n" "before it has been replaced will just hit the errors and fail..\n" "\n" - ">\302\240\n" + ">A \n" "\n" "<>\n" "\n" @@ -78,17 +78,17 @@ "\n" "<>\n" "> \n" - "> >\302\240\n" + "> >A \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" + "> > A - hits badblock\n" + "> > A - figures out it is able to recover the data\n" + "> > A - handles SIGBUS or EIO\n" + "> > A - does a (sector aligned) write() to restore the data\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" "> userspace, and userspace can't do that work in a signal handler.\n" - "> And it\302\240\302\240can still fall down to the second case when the application\n" + "> And itA A can still fall down to the second case when the application\n" "> doesn't have another copy of the data somewhere.\n" "\n" "Ah when I said \"figures out\" I was only thinking if the application has\n" @@ -103,16 +103,16 @@ "> \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" + "> > A - hits badblock\n" + "> > A - gets SIGBUS (or EIO) and crashes\n" + "> > A - Sysadmin restores file from backup\n" "> Which is no different to an existing non-DAX application getting an\n" "> EIO/sigbus from current storage technologies.\n" "> \n" "> Except: in the existing storage stack, redundancy and correction has\n" "> already had to have failed for the application to see such an error.\n" "> Hence this is normally considered a DR case as there's had to be\n" - "> cascading failures (e.g.\302\240\302\240multiple disk failures in a RAID) to get\n" + "> cascading failures (e.g.A A multiple disk failures in a RAID) to get\n" "> to this stage, not a single error in a single sector in\n" "> non-redundant storage.\n" "> \n" @@ -157,4 +157,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -455d0c8945f4ffc980c9c28eb0368e9a15387f5923701dfa90469b261fee71e3 +70a797651ead683aa1b9324f37c68af2c29cda2d9b3915cd2b98a5360ead62f1
diff --git a/a/1.txt b/N3/1.txt index 6dd9b01..7be3568 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -118,9 +118,3 @@ with DAX. > Cheers, > > Dave. - --- -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/N3/content_digest index cba8051..eadb6b4 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -149,12 +149,6 @@ "> \n" "> Cheers,\n" "> \n" - "> Dave.\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>" + > Dave. -455d0c8945f4ffc980c9c28eb0368e9a15387f5923701dfa90469b261fee71e3 +c5a473ccc4e59f9f334c0a549cf0e74be386b3a0db3da14c49b7dc47f73f8f27
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.