> On 4 Mar 2019, at 12.41, Hans Holmberg <[email protected]> wrote: > > On Mon, Mar 4, 2019 at 10:23 AM Javier González <[email protected]> wrote: >>> On 4 Mar 2019, at 10.02, Hans Holmberg <[email protected]> >>> wrote: >>> >>> Igor: Have you seen this happening in real life? >>> >>> I think it would be better to count all expected errors and put them >>> in the right bucket (without spamming dmesg). If we need a new bucket >>> for i.e. vendor-specific-errors, let's do that instead. >>> >>> Someone wiser than me told me that every error print in the log is a >>> potential customer call. >>> >>> Javier: Yeah, I think S.M.A.R.T is the way to deliver this >>> information. Why can't we let the drives expose this info and remove >>> this from pblk? What's blocking that? >> >> Until now the spec. We added some new log information in Denali exactly >> for this. But since pblk supports OCSSD 1.2 and 2.0 I think it is needed to >> have it here, at least for debugging. > > Why add it to the spec? Why not use whatever everyone else is using? > > https://en.wikipedia.org/wiki/S.M.A.R.T. : > "S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology; often > written as SMART) is a monitoring system included in computer hard > disk drives (HDDs), solid-state drives (SSDs),[1] and eMMC drives. Its > primary function is to detect and report various indicators of drive > reliability with the intent of anticipating imminent hardware > failures." > Sounds like what we want here.
I know what smart is… You need to define the fields. Maybe you want to read Denali again - the extensions are couple with smart. > For debugging, a trace point or something(i.e. BPF) would be a better > solution that would not impact hot-path performance. Cool. Look forward to the patches ;) Javier
signature.asc
Description: Message signed with OpenPGP
