HI ports@, Hi Fabian Raetz! Thanks for testing over two weeks and tweaks/feedback. Your rc changes works fine for me.
@ports: Attached new tarball with rc tweaks from Fabian Raetz. Could I get an okay (ports-wise) to import? Thanks, Rafael On Mon Jul 02, 2018 at 11:07:10PM +0200, Fabian Raetz wrote: > add here's the missing diff xD > > Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz < > fabian.ra...@gmail.com>: > > > Hi > > > > i've been running a bitcoin node for the last two weeks and everything > > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and > > used it in combination with lnd [0] (in testnet) > > > > Please find the attached diff with two small improvements to the rc file: > > - add daemon_timeout=300. The daemon need time to shutdown successfully > > (syncing to disk). 300 sec. was choosen randomly but this value worked for > > me in several restarts. > > - remove pid_file. It works even without specifying it. > > > > With this, the port looks ok to me :) > > > > Cheer, > > Fabian > > > > [0] https://github.com/lightningnetwork/lnd > > > > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski < > > raf...@sizeofvoid.org>: > > > >> 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}" > >> > >
bitcoin-0.16.1p0.tar.gz
Description: Binary data
