diff for duplicates of <4FDF9EBE.2030809@shiftmail.org> diff --git a/a/1.1.hdr b/N1/1.1.hdr index 2900622..5015eee 100644 --- a/a/1.1.hdr +++ b/N1/1.1.hdr @@ -1,2 +1,2 @@ Content-type: text/plain; charset=UTF-8; format=flowed -Content-Transfer-Encoding: 7BIT +Content-transfer-encoding: 7BIT diff --git a/a/1.2.hdr b/N1/1.2.hdr index 24ced0b..111a9a9 100644 --- a/a/1.2.hdr +++ b/N1/1.2.hdr @@ -1,3 +1,2 @@ Content-type: text/html; charset=UTF-8 -Content-Transfer-Encoding: quoted-printable -X-MIME-Autoconverted: from 8bit to quoted-printable by oss.sgi.com id q5ILXgsG243846 +Content-transfer-encoding: 8BIT diff --git a/a/2.hdr b/N1/2.hdr index 18d6893..4b86001 100644 --- a/a/2.hdr +++ b/N1/2.hdr @@ -1,4 +1,4 @@ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 -Content-Disposition: inline Content-Transfer-Encoding: 7bit +Content-Disposition: inline diff --git a/a/content_digest b/N1/content_digest index 3bf8c63..6c07e6f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -78,88 +78,88 @@ S. "\02:1.2\0" "b\0" - "<html>\r\n" - " <head>\r\n" - " <meta http-equiv=\"content-type\" content=\"text/html; charset=UTF-8\">\r\n" - " </head>\r\n" - " <body bgcolor=\"#FFFFFF\" text=\"#000000\">\r\n" - " Hello all<br>\r\n" - " I am doing some testing of dm-thin on kernel 3.4.2 and latest lvm\r\n" - " from source (the rest is Ubuntu Precise 12.04).<br>\r\n" - " There are a few problems with ext4 and (different ones with) xfs<br>\r\n" - " <br>\r\n" - " I am doing this:<br>\r\n" - " dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync<br>\r\n" - " lvs<br>\r\n" - " rm zeroes #optional<br>\r\n" - " dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync\302\240 #again<br>\r\n" - " lvs<br>\r\n" - " rm zeroes #optional<br>\r\n" - " ...<br>\r\n" - " dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync\302\240 #again<br>\r\n" - " lvs<br>\r\n" - " rm zeroes<br>\r\n" - " fstrim /mnt/mountpoint<br>\r\n" - " lvs<br>\r\n" - " <br>\r\n" - " On ext4 the problem is that it always reallocates blocks at\r\n" - " different places, so you can see from lvs that space occupation in\r\n" - " the pool and thinlv increases at each iteration of dd, again and\r\n" - " again, until it has allocated the whole thin device (really 100% of\r\n" - " it). And this is true regardless of me doing rm or not between one\r\n" - " dd and the other.<br>\r\n" - " The other problem is that by doing this, ext4 always gets the worst\r\n" - " performance from thinp, about 140MB/sec on my system, because it is\r\n" - " constantly allocating blocks, instead of 350MB/sec which should have\r\n" - " been with my system if it used already allocated regions (see below\r\n" - " compared to xfs). I am on an MD raid-5 of 5 hdds.<br>\r\n" - " I could suggest to add a \"thinp mode\" mount option to ext4 affecting\r\n" - " the allocator, so that it tries to reallocate recently used and\r\n" - " freed areas and not constantly new areas. Note that mount -o discard\r\n" - " does work and prevents allocation bloating, but it still always gets\r\n" - " the worst write performances from thinp. Alternatively thinp could\r\n" - " be improved so that block allocation is fast :-P (*) <br>\r\n" - " However, good news is that fstrim works correctly on ext4, and is\r\n" - " able to drop all space allocated by all dd's. Also mount -o discard\r\n" - " works.<br>\r\n" - " <br>\r\n" - " On xfs there is a different problem.<br>\r\n" - " Xfs apparently correctly re-uses the same blocks so that after the\r\n" - " first write at 140MB/sec, subsequent overwrites of the same file are\r\n" - " at full speed such as 350MB/sec (same speed as with non-thin lvm),\r\n" - " and also you don't see space occupation going up at every iteration\r\n" - " of dd, either with or without rm in-between the dd's. [ok actually\r\n" - " now retrying it needed 3 rewrites to stabilize allocation...\r\n" - " probably an AG count thing.]<br>\r\n" - " However the problem with XFS is that discard doesn't appear to work.\r\n" - " Fstrim doesn't work, and neither does \"mount -o discard ... + rm\r\n" - " zeroes\" . There is apparently no way to drop the allocated blocks,\r\n" - " as seen from lvs. This is in contrast to what it is written here\r\n" - " <meta http-equiv=\"content-type\" content=\"text/html; charset=UTF-8\">\r\n" - " <a href=\"http://xfs.org/index.php/FITRIM/discard\">http://xfs.org/index.php/FITRIM/discard</a>\r\n" - " which declare fstrim and mount -o discard to be working.<br>\r\n" - " Please note that since I am above MD raid5 (I believe this is the\r\n" - " reason), the passdown of discards does not work, as my dmesg says:<br>\r\n" - " [160508.497879] device-mapper: thin: Discard unsupported by data\r\n" - " device (dm-1): Disabling discard passdown.<br>\r\n" - " but AFAIU, unless there is a thinp bug, this should not affect the\r\n" - " unmapping of thin blocks by fstrimming xfs... and in fact ext4 is\r\n" - " able to do that.<br>\r\n" - " <br>\r\n" - " (*) Strange thing is that write performance appears to be roughly\r\n" - " the same for default thin chunksize and for 1MB thin chunksize. I\r\n" - " would have expected thinp allocation to be faster with larger thin\r\n" - " chunksizes but instead it is actually slower (note that there are no\r\n" - " snapshots here and hence no CoW). This is also true if I set the\r\n" - " thinpool to not zero newly allocated blocks: performances are about\r\n" - " 240 MB/sec then, but again they don't increase with larger\r\n" - " chunksizes, they actually decrease slightly with very large\r\n" - " chunksizes such as 16MB. Why is that?<br>\r\n" - " <br>\r\n" - " Thanks for your help<br>\r\n" - " S.<br>\r\n" - " </body>\r\n" - "</html>\r\n" + "<html>\n" + " <head>\n" + " <meta http-equiv=\"content-type\" content=\"text/html; charset=UTF-8\">\n" + " </head>\n" + " <body bgcolor=\"#FFFFFF\" text=\"#000000\">\n" + " Hello all<br>\n" + " I am doing some testing of dm-thin on kernel 3.4.2 and latest lvm\n" + " from source (the rest is Ubuntu Precise 12.04).<br>\n" + " There are a few problems with ext4 and (different ones with) xfs<br>\n" + " <br>\n" + " I am doing this:<br>\n" + " dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync<br>\n" + " lvs<br>\n" + " rm zeroes #optional<br>\n" + " dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync\302\240 #again<br>\n" + " lvs<br>\n" + " rm zeroes #optional<br>\n" + " ...<br>\n" + " dd if=/dev/zero of=zeroes bs=1M count=1000 conv=fsync\302\240 #again<br>\n" + " lvs<br>\n" + " rm zeroes<br>\n" + " fstrim /mnt/mountpoint<br>\n" + " lvs<br>\n" + " <br>\n" + " On ext4 the problem is that it always reallocates blocks at\n" + " different places, so you can see from lvs that space occupation in\n" + " the pool and thinlv increases at each iteration of dd, again and\n" + " again, until it has allocated the whole thin device (really 100% of\n" + " it). And this is true regardless of me doing rm or not between one\n" + " dd and the other.<br>\n" + " The other problem is that by doing this, ext4 always gets the worst\n" + " performance from thinp, about 140MB/sec on my system, because it is\n" + " constantly allocating blocks, instead of 350MB/sec which should have\n" + " been with my system if it used already allocated regions (see below\n" + " compared to xfs). I am on an MD raid-5 of 5 hdds.<br>\n" + " I could suggest to add a \"thinp mode\" mount option to ext4 affecting\n" + " the allocator, so that it tries to reallocate recently used and\n" + " freed areas and not constantly new areas. Note that mount -o discard\n" + " does work and prevents allocation bloating, but it still always gets\n" + " the worst write performances from thinp. Alternatively thinp could\n" + " be improved so that block allocation is fast :-P (*) <br>\n" + " However, good news is that fstrim works correctly on ext4, and is\n" + " able to drop all space allocated by all dd's. Also mount -o discard\n" + " works.<br>\n" + " <br>\n" + " On xfs there is a different problem.<br>\n" + " Xfs apparently correctly re-uses the same blocks so that after the\n" + " first write at 140MB/sec, subsequent overwrites of the same file are\n" + " at full speed such as 350MB/sec (same speed as with non-thin lvm),\n" + " and also you don't see space occupation going up at every iteration\n" + " of dd, either with or without rm in-between the dd's. [ok actually\n" + " now retrying it needed 3 rewrites to stabilize allocation...\n" + " probably an AG count thing.]<br>\n" + " However the problem with XFS is that discard doesn't appear to work.\n" + " Fstrim doesn't work, and neither does \"mount -o discard ... + rm\n" + " zeroes\" . There is apparently no way to drop the allocated blocks,\n" + " as seen from lvs. This is in contrast to what it is written here\n" + " <meta http-equiv=\"content-type\" content=\"text/html; charset=UTF-8\">\n" + " <a href=\"http://xfs.org/index.php/FITRIM/discard\">http://xfs.org/index.php/FITRIM/discard</a>\n" + " which declare fstrim and mount -o discard to be working.<br>\n" + " Please note that since I am above MD raid5 (I believe this is the\n" + " reason), the passdown of discards does not work, as my dmesg says:<br>\n" + " [160508.497879] device-mapper: thin: Discard unsupported by data\n" + " device (dm-1): Disabling discard passdown.<br>\n" + " but AFAIU, unless there is a thinp bug, this should not affect the\n" + " unmapping of thin blocks by fstrimming xfs... and in fact ext4 is\n" + " able to do that.<br>\n" + " <br>\n" + " (*) Strange thing is that write performance appears to be roughly\n" + " the same for default thin chunksize and for 1MB thin chunksize. I\n" + " would have expected thinp allocation to be faster with larger thin\n" + " chunksizes but instead it is actually slower (note that there are no\n" + " snapshots here and hence no CoW). This is also true if I set the\n" + " thinpool to not zero newly allocated blocks: performances are about\n" + " 240 MB/sec then, but again they don't increase with larger\n" + " chunksizes, they actually decrease slightly with very large\n" + " chunksizes such as 16MB. Why is that?<br>\n" + " <br>\n" + " Thanks for your help<br>\n" + " S.<br>\n" + " </body>\n" + "</html>\n" "\01:2\0" "b\0" "_______________________________________________\n" @@ -167,4 +167,4 @@ "xfs@oss.sgi.com\n" http://oss.sgi.com/mailman/listinfo/xfs -60ba8986651a8171009b26776bdabd6aec6dd8f51b4585316cb6ccff6843b805 +aaf5c244f8db0cbee0ff54a9d205d73f60f254d73a909cf10750f46314802101
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.