diff for duplicates of <20101109234049.GQ2715@dastard>

diff --git a/a/1.txt b/N1/1.txt
index c98d247..54e5998 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -2,7 +2,7 @@ On Tue, Nov 09, 2010 at 04:41:47PM -0500, Ted Ts'o wrote:
 > On Tue, Nov 09, 2010 at 03:42:42PM +1100, Dave Chinner wrote:
 > > Implementation is up to the filesystem. However, XFS does (b)
 > > because:
-> >=20
+> > 
 > > 	1) it was extremely simple to implement (one of the
 > > 	   advantages of having an exceedingly complex allocation
 > > 	   interface to begin with :P)
@@ -10,24 +10,23 @@ On Tue, Nov 09, 2010 at 04:41:47PM -0500, Ted Ts'o wrote:
 > > 	3) it is independent of the underlying storage; and
 > > 	4) reads of unwritten extents operate at memory speed,
 > > 	   not disk speed.
->=20
+> 
 > Yeah, I was thinking that using a device-style TRIM might be better
 > since future attempts to write to it won't require a separate seek to
 > modify the extent tree.  But yeah, there are a bunch of advantages of
 > simply mutating the extent tree.
->=20
+> 
 > While we're on the subject of changes to fallocate, what do people
 > think of FALLOC_FL_EXPOSE_OLD_DATA, which requires either root
 > privileges or (if capabilities are in use) CAP_DAC_OVERRIDE &&
-> CAP_MAC_OVERRIDE && CAP_SYS_ADMIN.  This would allow a trusted proces=
-s
+> CAP_MAC_OVERRIDE && CAP_SYS_ADMIN.  This would allow a trusted process
 > to fallocate blocks with the extent already marked initialized.  I've
-> had two requests for such functionality for ext4 already. =20
+> had two requests for such functionality for ext4 already.  
 
 We removed that ability from XFS about three years ago because it's
 a massive security hole. e.g. what happens if the file is world
 readable, even though the process that called
-=46ALLOC_FL_EXPOSE_OLD_DATA was privileged and was allowed to expose
+FALLOC_FL_EXPOSE_OLD_DATA was privileged and was allowed to expose
 such data? Or the file is chmod 777 after being exposed?
 
 The historical reason for such behaviour existing in XFS was that in
@@ -37,8 +36,7 @@ guns) were able to make use of fast preallocation with no conversion
 overhead without caring about the security implications. These days,
 the performance overhead of unwritten extent conversion is minimal -
 I generally can't measure a difference in IO performance as a result
-of it - so there is simply no good rea=D1=95on for leaving such a gapin=
-g
+of it - so there is simply no good reaѕon for leaving such a gaping
 security hole in the system.
 
 If anyone wants to read the underlying data, then use fiemap to map
@@ -46,11 +44,9 @@ the physical blocks and read it directly from the block device. That
 requires root privileges but does not open any new stale data
 exposure problems....
 
-> (Take for example a trusted cluster filesystem backend that checks th=
-e
+> (Take for example a trusted cluster filesystem backend that checks the
 > object checksum before returning any data to the user; and if the
-> check fails the cluster file system will try to use some other replic=
-a
+> check fails the cluster file system will try to use some other replica
 > stored on some other server.)
 
 IOWs, all they want to do is avoid the unwritten extent conversion
@@ -61,11 +57,10 @@ repeat it for ext4 today....
 Cheers,
 
 Dave.
---=20
+-- 
 Dave Chinner
 david@fromorbit.com
 --
-To unsubscribe from this list: send the line "unsubscribe linux-ext4" i=
-n
+To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
 the body of a message to majordomo@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N1/content_digest
index 72395e4..f66735f 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -19,7 +19,7 @@
  "> On Tue, Nov 09, 2010 at 03:42:42PM +1100, Dave Chinner wrote:\n"
  "> > Implementation is up to the filesystem. However, XFS does (b)\n"
  "> > because:\n"
- "> >=20\n"
+ "> > \n"
  "> > \t1) it was extremely simple to implement (one of the\n"
  "> > \t   advantages of having an exceedingly complex allocation\n"
  "> > \t   interface to begin with :P)\n"
@@ -27,24 +27,23 @@
  "> > \t3) it is independent of the underlying storage; and\n"
  "> > \t4) reads of unwritten extents operate at memory speed,\n"
  "> > \t   not disk speed.\n"
- ">=20\n"
+ "> \n"
  "> Yeah, I was thinking that using a device-style TRIM might be better\n"
  "> since future attempts to write to it won't require a separate seek to\n"
  "> modify the extent tree.  But yeah, there are a bunch of advantages of\n"
  "> simply mutating the extent tree.\n"
- ">=20\n"
+ "> \n"
  "> While we're on the subject of changes to fallocate, what do people\n"
  "> think of FALLOC_FL_EXPOSE_OLD_DATA, which requires either root\n"
  "> privileges or (if capabilities are in use) CAP_DAC_OVERRIDE &&\n"
- "> CAP_MAC_OVERRIDE && CAP_SYS_ADMIN.  This would allow a trusted proces=\n"
- "s\n"
+ "> CAP_MAC_OVERRIDE && CAP_SYS_ADMIN.  This would allow a trusted process\n"
  "> to fallocate blocks with the extent already marked initialized.  I've\n"
- "> had two requests for such functionality for ext4 already. =20\n"
+ "> had two requests for such functionality for ext4 already.  \n"
  "\n"
  "We removed that ability from XFS about three years ago because it's\n"
  "a massive security hole. e.g. what happens if the file is world\n"
  "readable, even though the process that called\n"
- "=46ALLOC_FL_EXPOSE_OLD_DATA was privileged and was allowed to expose\n"
+ "FALLOC_FL_EXPOSE_OLD_DATA was privileged and was allowed to expose\n"
  "such data? Or the file is chmod 777 after being exposed?\n"
  "\n"
  "The historical reason for such behaviour existing in XFS was that in\n"
@@ -54,8 +53,7 @@
  "overhead without caring about the security implications. These days,\n"
  "the performance overhead of unwritten extent conversion is minimal -\n"
  "I generally can't measure a difference in IO performance as a result\n"
- "of it - so there is simply no good rea=D1=95on for leaving such a gapin=\n"
- "g\n"
+ "of it - so there is simply no good rea\321\225on for leaving such a gaping\n"
  "security hole in the system.\n"
  "\n"
  "If anyone wants to read the underlying data, then use fiemap to map\n"
@@ -63,11 +61,9 @@
  "requires root privileges but does not open any new stale data\n"
  "exposure problems....\n"
  "\n"
- "> (Take for example a trusted cluster filesystem backend that checks th=\n"
- "e\n"
+ "> (Take for example a trusted cluster filesystem backend that checks the\n"
  "> object checksum before returning any data to the user; and if the\n"
- "> check fails the cluster file system will try to use some other replic=\n"
- "a\n"
+ "> check fails the cluster file system will try to use some other replica\n"
  "> stored on some other server.)\n"
  "\n"
  "IOWs, all they want to do is avoid the unwritten extent conversion\n"
@@ -78,13 +74,12 @@
  "Cheers,\n"
  "\n"
  "Dave.\n"
- "--=20\n"
+ "-- \n"
  "Dave Chinner\n"
  "david@fromorbit.com\n"
  "--\n"
- "To unsubscribe from this list: send the line \"unsubscribe linux-ext4\" i=\n"
- "n\n"
+ "To unsubscribe from this list: send the line \"unsubscribe linux-ext4\" in\n"
  "the body of a message to majordomo@vger.kernel.org\n"
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
-760680fdc9510319c589894900fadff1547248841c3e96046e3a9f3298bdabea
+845a5cabb34a53a987a8969dcb31463a0e770d7552a7e2fcf2e88e39d624b87e
