On Wed, July 4, 2018 23:28, Rafael Sadowski wrote: > 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?
Hi! Not an OK yet, sorry. I guess better comment is needed to explain why this could be built with clang only. And since almost all @tag bits are in, it would be nice to use it in new ports instead of @exec. > > 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 < >> [email protected]>: >> >> > 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 < >> > [email protected]>: >> > >> >> 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 <[email protected]> >> >> wrote: >> >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +0000, [email protected] >> >> 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 < >> >> [email protected]> 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}" >> >> >> > > > >
