diff for duplicates of <20170114004910.GA4880@omniknight.lm.intel.com> diff --git a/a/1.txt b/N1/1.txt index f8699b1..9a8deba 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -59,7 +59,7 @@ filesystem can do. > > > > 1. Filesystems develop a native representation of badblocks. For > > example, in xfs, this would (presumably) be linked to the reverse -> > mapping btree. The filesystem representation has the potential to be� +> > mapping btree. The filesystem representation has the potential to be > > more efficient than the block driver doing the check, as the fs can > > check the IO happening on a file against just that file's range. > @@ -129,7 +129,7 @@ they will just trigger a SIGBUS, and there's no way around that. > > >In contrast, today, the block driver checks against the whole block device > > range for every IO. On encountering badblocks, the filesystem can -> > generate a better notification/error message that points the user to� +> > generate a better notification/error message that points the user to > > (file, offset) as opposed to the block driver, which can only provide > > (block-device, sector). > > @@ -161,3 +161,8 @@ when it discovers a badblock it will do the remapping. But since this is on the memory bus, and has different error signatures than applications are used to, we want to make the error handling similar to the existing storage model. + +_______________________________________________ +Linux-nvdimm mailing list +Linux-nvdimm@lists.01.org +https://lists.01.org/mailman/listinfo/linux-nvdimm diff --git a/a/content_digest b/N1/content_digest index 338aeb8..8a3412d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,11 +5,11 @@ "Subject\0Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems\0" "Date\0Fri, 13 Jan 2017 17:49:10 -0700\0" "To\0Slava Dubeyko <Vyacheslav.Dubeyko@wdc.com>\0" - "Cc\0lsf-pc@lists.linux-foundation.org <lsf-pc@lists.linux-foundation.org>" - linux-nvdimm@lists.01.org <linux-nvdimm@lists.01.org> - linux-block@vger.kernel.org <linux-block@vger.kernel.org> + "Cc\0linux-block@vger.kernel.org <linux-block@vger.kernel.org>" Linux FS Devel <linux-fsdevel@vger.kernel.org> - " Viacheslav Dubeyko <slava@dubeyko.com>\0" + lsf-pc@lists.linux-foundation.org <lsf-pc@lists.linux-foundation.org> + Viacheslav Dubeyko <slava@dubeyko.com> + " linux-nvdimm@lists.01.org <linux-nvdimm@lists.01.org>\0" "\00:1\0" "b\0" "On 01/14, Slava Dubeyko wrote:\n" @@ -73,7 +73,7 @@ "> > \n" "> > 1. Filesystems develop a native representation of badblocks. For\n" "> > example, in xfs, this would (presumably) be linked to the reverse\n" - "> > mapping btree. The filesystem representation has the potential to be\303\257\302\277\302\275\n" + "> > mapping btree. The filesystem representation has the potential to be\302\240\n" "> > more efficient than the block driver doing the check, as the fs can\n" "> > check the IO happening on a file against just that file's range. \n" "> \n" @@ -143,7 +143,7 @@ "> \n" "> >In contrast, today, the block driver checks against the whole block device\n" "> > range for every IO. On encountering badblocks, the filesystem can\n" - "> > generate a better notification/error message that points the user to\303\257\302\277\302\275\n" + "> > generate a better notification/error message that points the user to\302\240\n" "> > (file, offset) as opposed to the block driver, which can only provide\n" "> > (block-device, sector).\n" "> >\n" @@ -174,6 +174,11 @@ "when it discovers a badblock it will do the remapping. But since this is\n" "on the memory bus, and has different error signatures than applications\n" "are used to, we want to make the error handling similar to the existing\n" - storage model. + "storage model.\n" + "\n" + "_______________________________________________\n" + "Linux-nvdimm mailing list\n" + "Linux-nvdimm@lists.01.org\n" + https://lists.01.org/mailman/listinfo/linux-nvdimm -6902944dfe4e6a71775d5c2ea75af01c0b139130b950799c081e4726bbdadb4e +ac0660733e85861e1e56a7f6004e18c747164c3697404560904f8733443de805
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.