From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 8E2647AD20 for ; Mon, 10 May 2021 14:35:44 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 7A7FE18723 for ; Mon, 10 May 2021 14:35:14 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id CB73118718 for ; Mon, 10 May 2021 14:35:13 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 816EE46191 for ; Mon, 10 May 2021 14:35:13 +0200 (CEST) Date: Mon, 10 May 2021 14:35:11 +0200 From: Oguz Bektas To: Dominik Csapak Cc: Proxmox VE development discussion Message-ID: <20210510123511.GB9727@gaia.proxmox.com> Mail-Followup-To: Oguz Bektas , Dominik Csapak , Proxmox VE development discussion References: <20210401134055.701355-1-o.bektas@proxmox.com> <20210401142402.819548-1-o.bektas@proxmox.com> <6fbe66e5-0ecb-6f21-57e6-89f9b6828571@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6fbe66e5-0ecb-6f21-57e6-89f9b6828571@proxmox.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-SPAM-LEVEL: Spam detection results: 1 AWL 1.191 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH v2 storage 2/2] smartctl: use json parsing X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2021 12:35:44 -0000 thanks for reviewing! :) On Mon, May 10, 2021 at 02:21:12PM +0200, Dominik Csapak wrote: > some comments inline > > > } > > - my $cmd = [$SMARTCTL, '-H']; > > - push @$cmd, '-A', '-f', 'brief' if !$healthonly; > > + my $cmd = [$SMARTCTL, '-j', '-H']; > > + push @$cmd, '-Afbrief' if !$healthonly; > > any particular reason to change this line? i think > it makes it harder to read what flags we give > (-Afbrief vs -A -f brief) i think my idea was that the cli parameter count for the disklist_test.pm would be reduced -- but i notice that actually this doesn't bring anything so i suppose we can leave this part out. > > + if ($format eq 'text') { > > + foreach my $key (sort keys %{$nvme_info}) { > > + my $value = $nvme_info->{$key}; > > + # some fields can also be arrays > > + # e.g. temperature_sensor > > + if (ref($value) eq 'ARRAY') { > > + while (my $index = each(@$value)) { > > + $add_key->("${key}_${index}", $value->[$index]); > > + } > > while this is ok, we probably could also do a > 'pretty-print' json output here in case $value is not a scalar > > that way we would also catch (potential) objects, not only arrays > (though i do not know if that can happen) hmm yes, haven't seen any other examples besides that array case, but i will look into it. > + my @sorted_attributes = sort { $a->{id} <=> $b->{id} } @{$smartdata->{attributes}}; > > + @{$smartdata->{attributes}} = @sorted_attributes; > > + } > > - # bit 0 and 1 mark an severe smartctl error > > - # all others are for disk status, so ignore them > > - # see smartctl(8) > > - if ((defined($returncode) && ($returncode & 0b00000011)) || $err) { > > + if ($returncode & 0b00000011 || $err) { > > again, any reason to change this? especially the comment about the return > code ? the comment was removed by mistake, sorry! i was also thinking whether it's acceptable to take the exit code from the json result (although then we might have to handle for potential errors during parsing, so it might be better to keep it as before)