Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: Debugging CPAN problem

by davies (Prior)
on Dec 22, 2020 at 20:42 UTC ( [id://11125638]=note: print w/replies, xml ) Need Help??


in reply to Debugging CPAN problem

++ to those who recommended cpanm - it's one of the first things I install on a Pi. SD cards have a limited life - about 1K writes before things start to fail (they can usually handle small failing areas). All my production Pis therefore have a second SD card on a USB adapter. The following code is on them all & run whenever I make a material change. This means that I can swap the card immediately whenever one dies.

#!/usr/bin/perl use strict; use warnings; use feature 'say'; use constant DEBUG => 0; my %tree; my @tree = split(/\n/, `lsblk -bnlo NAME,SIZE,MOUNTPOINT`); for (@tree) { my ($key, $size, $mount) = (split(/\s+/, $_)); $key =~ s/\d.*//; if ($key =~ m/^sd*/ or $key eq 'mmcblk') { $tree{$key}{'mount'} = $mount; $tree{$key}{'size'} = $size unless defined $tree{$key}{'size' +}; } } my $target; use Data::Dumper; print Dumper %tree if DEBUG; for (keys %tree) { if ('' eq $tree{$_}{'mount'}) { $target = $_; last; } } die 'No target found!' unless $target; my $cmd = "sudo dd if=/dev/mmcblk0 of=/dev/$target bs=1M"; say $cmd if DEBUG; if ($tree{$target}{'size'} >= $tree{'mmcblk'}{'size'}) { say 'Backing up - target large enough.'; } else { die "Can't back up with source larger than target."; } exec $cmd unless DEBUG; =pod =head1 NAME AND SYNOPSIS sdbackup.pl =head1 DESCRIPTION This is a standalone programme to be invoked manually. It is written for a Raspberry Pi with a second SD card attached via a USB adaptor. On the original target, dns, there is a thumb drive mounted for logging. The code is therefore designed to look for an unmounted device on one of the "sd" interfaces. If such a device is found, the main SD card will be copied to it unless the target is smaller than the source. The backup will take roughly 1.2 minutes per meg. It will back up to the first unmounted attached block device that appears in the hash created from the 'lsblk' command. If there are two or more unmounted devices, the target may not be predictable. =head2 Constants The only constant is DEBUG. If this is set to a value Perl treats as true, no backup will be performed and a hash will dumped before the command candidate is printed. Otherwise the backup will be started unless the target is smaller than the source. =head2 Constraints The code relies on the behaviour of 'lsblk' and in particular its property of listing the block device before the partitions. It also relies on the name of the mounted SD card starting with 'mmcblk' followed by a digit. If there is more than one such device, behaviour may be unpredictable. =head2 lsblk parameters =over * b - Show device sizes in bytes. * n - No headings * l - Use list format * o - Output the columns in the list that follows. =back =cut

Regards,

John Davies

Replies are listed 'Best First'.
Re^2: Debugging CPAN problem
by stevieb (Canon) on Dec 22, 2020 at 23:02 UTC
    "SD cards have a limited life - about 1K writes before things start to fail"

    Holy crap! 1k writes only? What kind of cards are you buying? I have several Pis (eight, 10 if I include my zeroWs), a couple of them that have been running for several years (literally) doing all manner of intense disk activity constantly, and I've only ever had two cards fail on me over that span across all of my Pis, and one was a direct result of accidentally applying 48v DC to the power pin while I had it connected to an SD reader while I was writing software for a micro controller.

    I use mainly Kingston cards.

      My father always used to ask, "Is that something you know or something you've been told?". This is what I have been told. SD cards have logic that spreads the writes around so that no one point gets lots of hits. If you do a complete overwrite - which is what my code does - 1K times, you are reaching the end of the useful life of the device. When I put this to a salesman of SSDs, he did not deny the basic arguments but said that the power consumption more than made up for the shorter life (than spinning rust) and that in most cases, data were written far fewer times than read and that the read speed was a further advantage and and and. But he didn't deny the effective write limit, although I have no hard evidence for the 1K figure I had been told. I'll bet that, over time, the number of writes will increase. The cards I have that have failed most are Verbatim, but I have other reasons for avoiding anything of that brand in future.

      Regards,

      John Davies

        I have no hard evidence for the 1K figure I had been told.

        What I learned when studying this years ago is that flash cells have an endurance of more like around 10k writes, though I'm sure with the advancement of the technology that's increased* (I've head figures of up to 1M writes). Conversely, the wide spread of flash technology also means that there will probably be companies producing cheap, lower-quality flash, with less write cycles.

        * I went on DigiKey and picked a few current NAND Flash ICs at random, from different manufacturers (PDFs: 1, 2, 3) and each of them specifies an endurance of 100K Program/Erase cycles and data retention of 10 years.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11125638]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (4)
As of 2024-03-29 13:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found