Merge branch 'master' of github.com:nikiroo/gofetch

[gofetch.git] / test / expected / LWN / 0000763603.header.html
diff --git a/test/expected/LWN/0000763603.header.html b/test/expected/LWN/0000763603.header.html

index 10fb39a422810b319bf248b318bcf0aad90db69f..ceec6b4cd59cae91d0a8f732a58e14f1240f0456 100644 (file)
--- a/test/expected/LWN/0000763603.header.html
+++ b/test/expected/LWN/0000763603.header.html
@@ -9,11 +9,11 @@
  </head>
  <body>
  <div class='story-header'>
-       <h1><a href='0000763603.html'>[$] Measuring (and fixing) I/O-controller throughput loss</a></h1>
+       <h2><a href='0000763603.html'>[$] Measuring (and fixing) I/O-controller throughput loss</a></h2>
         <div class='details'>([Kernel] Aug 29, 2018 21:20 UTC (Wed) (corbet))</div>
         <br/>
         <div class='content' style='text-align: justify'>
-               Many services, from web hosting and video streaming to cloud storage, need to move data to and from storage. They also often require that each per-client I/O flow be guaranteed a non-zero amount of bandwidth and a bounded latency. An expensive way to provide these guarantees is to over-provision storage resources, keeping each resource underutilized, and thus have plenty of bandwidth available for the few I/O flows dispatched to each medium. Alternatively one can use an I/O controller. Linux provides two mechanisms designed to throttle some I/O streams to allow others to meet their bandwidth and latency requirements. These mechanisms work, but they come at a cost: a loss of as much as 80% of total available I/O bandwidth. I have run some tests to demonstrate this problem; some upcoming improvements to the bfq I/O scheduler promise to improve the situation considerably.
+               Many services, from web hosting and video streaming to cloud storage, need to move data to and from storage. They also often require that each per-client I/O flow be guaranteed a non-zero amount of bandwidth and a bounded latency. An expensive way to provide these guarantees is to over-provision storage resources, keeping each resource underutilized, and thus have plenty of bandwidth available for the few I/O flows dispatched to each medium. Alternatively one can use an I/O controller. Linux provides two mechanisms designed to throttle some I/O streams to allow others to meet their bandwidth and latency requirements. These mechanisms work, but they come at a cost: a loss of as much as 80% of total available I/O bandwidth. I have run some tests to demonstrate this problem; some upcoming improvements to the [1]bfq I/O scheduler promise to improve the situation considerably.<br/><br/><br/><br/>[1] https://lwn.net/Articles/601799/
         </div>
  <hr/>
  </div>