On 2018-06-23 09:07:38, Thomas Frohwein <tfrohw...@fastmail.com> wrote:
> On Fri, Jun 08, 2018 at 11:38:49AM +0000, tfrohw...@fastmail.com wrote:
> > I think the blockchain size is a deterrent. I can test it when I'm back
> > from traveling in ~ 10 days and have access to additional GB on my external
> > drive, in case that helps.
> >
> > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <raf...@sizeofvoid.org>
> > wrote:
> > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > >
> > >It's not evil! It's NOT mining. ;)
>
> I installed it and tried to sync the 200GB blockchain to my external HDD
> (because that's the only one that got this much space available). It
> synced fine for 1-2 days with the bitcoin-qt client, but then at about
> 30-40% of the blockchain synced, it now starts throwing an error:
>
> ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread
> failed: unspecified iostream_category error at CBlockDiskPos(nFile=613,
> nPos=6513581)
>
> When this happens, the following lines appear in dmesg:
>
> sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> SENSE KEY: Media Error
> ASC/ASCQ: Unrecovered Read Error
>
> Fortunately, the drive still seems to be functional otherwise, can be
> mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> whenever mounting or unmounting said drive until I disconnect and
> reconnect the drive from the USB port.
>
This is almost certainly a problem with the drive. I've had
several hard drives fail over the ~13 years or so I've been using
OpenBSD, and this is exactly the kind of error I see when the
drive is wearing out.
The message means that the kernel could not read a sector on the
drive despite trying to do so. I've had drives continue to
otherwise work for years after throwing errors like that (though I
made sure to back them up and only used them as "scratch" drives).
Another time I had a drive fail within weeks of throwing an error
like that.
If it's still under warranty, I'd recommend sending it in for
replacement. If it's not, I'd *highly* recommend backing up
anything on there to another drive.
Sometimes, sectors can be "weak" and if you give the drive enough
time it will be able to read it, so if it can't be backed up
entirely, back up as much as you can, then let the drive sit for a
few days and try again.
Some ports that may help:
sysutils/ddrescue
sysutils/testdisk
sysutils/e2fsprogs (for the "badblocks" program)
net/rsync (probably obvious, but still worth mentioning)
Modern drives keep "spare sectors" in which to remap failing ones
like this, but they usually only do so when *writing* to the
sector, not when *reading* it.
You could try backing up the drive, then writing zeros to the
entire drive with dd(1) to try to see if it helps. You could also
try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
-n Use non-destructive read-write mode. By default only a non-
destructive read-only test is done. This option must not be
combined with the -w option, as they are mutually exclusive.
"badblocks -n" will read all sectors on the drive and write back
the same data to the sector. If it's "weak", and the program can
manage to read the sector, the drive may then remap that sector to
a spare.
But! How much do you really trust a drive that has started to
fail? Drives are cheap. Cheaper than they've ever been. If this
drive contains the only copy of family photos of your dearly
departed grandmother, are you willing to risk it?
sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4 0/direct
fixed
sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
I see a 3TB Western Digital My Book on a very popular online
retailer for only $89.99 USD with free shipping as I type this.
Is the data on that drive worth more than that? Is the amount of
time you'd spend trying to squeeze a little more life out of the
drive worth it? How much do you value your free time? If you
enjoy tinkering with things like this and don't have valuable data
on it, it may be worth trying. If you'd rather spend that time
outside hiking or seeing friends and family, then it may be more
economical to just buy a new one.
Ultimately, only you can decide.
> I can't resume syncing the blockchain though because the error appears
> again.
>
While I'm here, I poked around bitcoin's manpage and found this:
-prune=<n>
Reduce storage requirements by enabling pruning (deleting) of
old blocks. This allows the pruneblockchain RPC to be called to
delete specific blocks, and enables automatic pruning of old
blocks if a target size in MiB is provided. This mode is
incompatible with -txindex and -rescan. Warning: Reverting this
setting requires re-downloading the entire blockchain. (default:
0 = disable pruning blocks, 1 = allow manual pruning via RPC,
>550 = automatically prune block files to stay under the
specified target size in MiB)
I have no idea if this only works *after* downloading the entire
blockchain or not, but it might be worth trying this option and
seeing if it will obviate the need for downloading 200+ GB of
data.
Rafael:
If setting this option works out-of-the-box, it might be worth
making a note of it. Reading back through the thread, I see some
people saying that they couldn't test or use the port because they
don't have 200 GB of space for it.
If it works, it might be worth adding a note to MESSAGE or a
README since this is probably going to be a common issue for most
people.
> Not sure if this is a deficiency of the port or maybe the hard drive
> itself...
>
As said above, it's almost certainly the drive. Please be sure to
back up anything important as soon as you can.
--
Bryan
