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
bitcoin-0.16.1.tar.gz
Description: Binary data
