On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
> On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
> > 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
> >
>
> Thanks Bryan Linton for the pruning hint. Thomas, I think, just like
> Bryan, your problem is a storage issue not an bitcoin(d).
>
> Please find attached a new tarball with following changes/improvements:
>
> - Update from bitcoin-0.16.0 to bitcoin-0.16.1
> - Replace MESSAGE by README:
> -- RPC user and password
> -- Storage requirements
>
> Still waiting for a final okay
For all fast cowboys, there is a quoting issue reported by David Hill.
Please change MAKE_FLAGS to:
MAKE_FLAGS = CC="${CC}" CXX="${CXX}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}"
