Add bad block count histograms

tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 50223f0c9c5ec120a5cc0b11095122db81edaa6d..117333ddbcbbdbf8fa65b56035a6f7e547ff4257 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -19344,6 +19344,15 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   <summary>Chrome OS stateful partition usage level.</summary>
 </histogram>
 
+<histogram name="Platform.Storage.Flash.BadBlocks">
+  <owner>dehrenberg@chromium.org</owner>
+  <summary>
+    The number of blocks marked bad in an MTD partition. This is relevant for
+    devices with raw NAND flash, such as Chromecast. Sampled once daily, if the
+    Chromecast is on for any significant length of time in the day.

[Ilya Sherman, 2014/06/17 21:07:05]

So... is this being sampled during shutdown?  If so, is there a chance that logs
might get lost due to unclean shutdowns?  Or is it assumed that the Chromecast
is always on, just mostly idle?  Is that actually a fair assumption?

IMO it would be great to list the specific event that triggers sampling
(assuming there's something more to say), and then to think about whether there
are any potential sources of bias from this sampling approach.  If so, it's wise
to list the most relevant potential sources of bias as caveats, so that anyone
viewing this data knows what to watch out for.

[dehrenberg, 2014/06/17 21:15:36]

I'm not sure how much detail I should go into--it's pretty boring.

There's a daemon which wakes up every 100 ms and checks whether it's a new day
by checking the timestamp of a special file which it updates. If it sees that
it's a new day, then it tries to upload the bad block counts. But the device may
be shut down before it gets the chance to send it, so it's not so reliable if
it's been the new day for a very short amount of time. No events trigger
sampling beyond the device being on.

Should I put that in the summary?

[Ilya Sherman, 2014/06/17 21:32:34]

Thanks.  I think the summary is probably fine as is, given this mechanism.

+  </summary>
+</histogram>
+
 <histogram name="Platform.SwapInLong" units="pages/second">
   <owner>sonnyrao@chromium.org</owner>
   <summary>
@@ -45548,6 +45557,27 @@ Therefore, the affected-histogram name has to have at least one dot in it.
   <affected-histogram name="Autofill.Quality.ServerType.ByFieldType"/>
 </histogram_suffixes>
 
+<histogram_suffixes name="BadBlockCounts" separator=".">
+  <suffix name="Backupsys" label="backupsys partition"/>
+  <suffix name="Bbt" label="bbt partition"/>
+  <suffix name="Block0" label="block0 partition"/>
+  <suffix name="Bootloader" label="bootloader partition"/>
+  <suffix name="Cache" label="cache partition"/>
+  <suffix name="Factory_store" label="factory_store partition"/>
+  <suffix name="Fts" label="fts partition"/>
+  <suffix name="Kernel" label="kernel partition"/>
+  <suffix name="Postbootloader" label="postbootloader partition"/>
+  <suffix name="Postbootloader-B" label="postbootloader-B partition"/>
+  <suffix name="Prebootloader" label="prebootloader partition"/>
+  <suffix name="Recovery" label="recovery partition"/>
+  <suffix name="Rootfs" label="rootfs partition"/>
+  <suffix name="Total" label="total partition"/>
+  <suffix name="TZ" label="TZ partition"/>
+  <suffix name="TZ-B" label="TZ-B partition"/>
+  <suffix name="Userdata" label="userdata partition"/>
+  <affected-histogram name="Platform.Storage.Flash.BadBlocks"/>
+</histogram_suffixes>
+
 <histogram_suffixes name="CacheListSize">
   <suffix name="CacheListSize_12" label="Control"/>
   <suffix name="CacheListSize_13" label="Extended deleted list (2x)"/>