[01:00:25] *** Quits: ziyeyang_ (ziyeyang@nat/intel/x-vlcsltthitskywoj) (Remote host closed the connection) [01:21:19] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Quit: Page closed) [01:26:46] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [02:52:59] *** Joins: tomzawadzki (tomzawadzk@nat/intel/x-fzhxizyoeoqhkvbh) [03:04:49] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [07:43:39] *** Quits: lhodev (~Adium@inet-hqmc02-o.oracle.com) (Remote host closed the connection) [08:19:35] *** Joins: lhodev (~Adium@inet-hqmc04-o.oracle.com) [08:54:54] wrt John's historgram patch where I updated the changeid, not sure I've seen this CI status before, what does it mean? https://review.gerrithub.io/#/c/363114/ [09:06:39] oh, geeze. seg fault running nvme identify tests. I'll try running again [09:10:04] ugh...wrong irc window :) [10:08:32] *** Quits: sethhowe (~sethhowe@134.134.139.83) (Remote host closed the connection) [10:43:14] *** Joins: sethhowe (~sethhowe@134.134.139.83) [10:45:13] bwalker, I'll actually review you large IO channel doc patch if you go take a look at this :) https://review.gerrithub.io/#/c/386186/ [10:46:20] ok [10:58:30] *** Quits: tomzawadzki (tomzawadzk@nat/intel/x-fzhxizyoeoqhkvbh) (Ping timeout: 260 seconds) [11:35:37] *** Quits: lhodev (~Adium@inet-hqmc04-o.oracle.com) (Remote host closed the connection) [11:45:59] *** Joins: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) [12:46:34] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [13:42:46] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [13:44:43] *** Joins: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) [14:41:52] bwalker, in a review comment wrt GC, you state "The larger the number of "reserved" erase blocks, the longer garbage collection can be delayed. " however from what I recall, and its been a few years since I've been close to this kinda stuff, just the opposite is true. The EBs are reserved for GC so fewer means more of a chance for delays, not more. What am I missing? [14:44:32] I don't think the two statements you just made are related to one another [14:44:40] reserving EBs serves two purposes [14:44:46] one is so that you always have some spare for GC [14:45:18] but the other is to minimize garbage collection, which is a more subtle thing [14:45:30] if you think of the drive as a big log - a linked list of EBs [14:46:04] new writes go to the front of the log [14:46:37] and eventually EBs fall off the back, which means the drive goes through each block on that EB, determines if the data is still "live" in the FTL, and moves it to the front of the log if it is [14:47:00] if the ratio of spare space to exposed space gets larger, it takes longer for EBs to fall off the back [14:47:30] where time is really measured in number of blocks written [14:48:00] the longer it takes an EB to fall off the back, the more statistically likely it is that it contains no valid "live" data [14:48:21] because as time goes on, more blocks are written to the front of the log, invalidating the data on the older EBs [14:48:29] again, time is in units of blocks written [14:48:57] the more spread out the logical block numbers are, the more likely this strategy works [14:49:12] if you writing to the same block over and over again of course it then doesn't matter [14:49:37] bwalker, awesome thanks! I hadn't thought of that... [14:50:26] that's a pretty subtle nuance of SSD design that I don't see talked about much, but it makes a huge difference [14:52:07] if you just had to have spare EBs for GC, you'd only keep as many spare EBs as your total background GC bandwidth could process at once [14:52:27] and that's probably like 8 or something [14:52:57] but enterprise drives withhold between 10 and 20% of the total NAND for the more nuanced reason above [14:59:42] interesting... [15:46:21] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) [15:50:03] *** Quits: gila (~gila@5ED4D9C8.cm-7-5d.dynamic.ziggo.nl) (Quit: My Mac Pro has gone to sleep. ZZZzzz…) [19:04:49] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Ping timeout: 260 seconds) [21:41:37] *** Joins: ziyeyang_ (ziyeyang@nat/intel/x-gtokukmqpeadaexu) [21:59:13] *** Quits: ziyeyang_ (ziyeyang@nat/intel/x-gtokukmqpeadaexu) (Quit: Leaving) [23:07:51] *** Quits: lhodev (~Adium@66-90-218-190.dyn.grandenetworks.net) (Ping timeout: 240 seconds) [23:30:39] *** Joins: lhodev (~Adium@66.90.218.190)