< fanquake>
promag: I've added them. Adding/removing things from the project boards requires permissions that also let you do a bunch of other things on the repository, that we don't need everyone having access too.
< ossifrage>
wow, bitcoin seems to run much faster on a mdraid10+xfs vs btrfs+raid1
< ossifrage>
(same drives)
< ossifrage>
it has been grinding through 11 weeks of mainnet blocks at a nice rate
< BlueMatt>
btrfs eats databases cause cow/checksumming, also raid1 vs raid10....
< ossifrage>
BlueMatt, only 2 disks
< ossifrage>
I had a drive get knocked off the bus due to some 'event' and the recovery was a torture, never had the same problems with mdraid
< BlueMatt>
point being apples != oranges.
< ossifrage>
btrfs seems to have bugs related to it throwing ENOSPC and getting in a state where you can't mount it rw anymore (and no recovery path)
< ossifrage>
BlueMatt, it is effectively the same mirrored disk layout, I just used the raid10 driver because it did a good job at starting the array in a degraded state
< BlueMatt>
google cow/btrfs checksumming
< ossifrage>
Yeah I had btrfs screw up all the checksums when doing CoW + vmware
< BlueMatt>
btrfs is verrryyyy different than xfs
< ossifrage>
but I was committed to it at that point, didn't have enough space to recover
< ossifrage>
this failure mode gave me a chance to dump btrfs
< ossifrage>
(mounted half the btrfs and created half a mdraid+xfs, copied the data over and then rebuilt the array)
< ossifrage>
But I did get bitten by dedupe, I forgot I had deduped the btrfs volume and when copying over the data I tarballed some of the stuff and ended up using 50G more
< ossifrage>
Crap: 2020-01-21T05:25:47.282128Z *** Disk space is too low!
< ossifrage>
huh, the bitcoin-qt UI won't raise after throwing the low disk space error
< luke-jr>
BlueMatt: ZFS does CoW/checksumming and doesn't perform terrible FWIW
< ossifrage>
one really annoying thing with btrfs is it doesn't spread raid1 reads uniformly over both drives
< ossifrage>
it does some stupid pid&1 thing to figure which drive gets the io
< ossifrage>
The bitcoin-qt UI really didn't like running out of disk, I wasn't able to raise it and I ended up having to do a hard kill to get it to exit
< luke-jr>
if it ran out of space, it should be shutting down
< luke-jr>
which can take some time
< ossifrage>
it didn't seem to be making any progress shutting down (or any sign in the log that it was trying)
< luke-jr>
might be a bug
< luke-jr>
or if the disk was completely full, it might have been blocking
< ossifrage>
(I freed up 12G right away)
< ossifrage>
after the 'too low' message all I got was ping and socket send timeouts in the log
< luke-jr>
anyway, I definitely wouldn't advise using btrfs. I still have some, and almost always regret not migrating it, when I access it
< ossifrage>
luke-jr, I was happy to finally get rid of it
< ossifrage>
but the process was rather painful (especially when it turned out nothing was wrong with the drive)
< kallewoof>
I just realized that both of the two macos fixes I have PR:s for will, combined, fix the APFS pre-allocation issue. As long as you ftruncate to the pre-allocated size, the system will successfully reclaim space when you shrink the file later. I.e. preallocate 1 mb; truncate 128 b -> 1 mb file, whereas preallocate 1 mb, truncate 1 mb, truncate 128 b -> 4 k (or whatever the sector (?) size happens to be).
< kallewoof>
Actually, even better.. the F_PREALLOCATE fix alone will fix it, since it does the truncation correctly.
< kallewoof>
Actually#2, it seems like you don't even need to ftruncate to the file size in question, you just need to be near it. Which is good, since we are over-pre-allocating by up to <chunk size>.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #17972: tests: Add fuzzing harness for CKey and key related functions (master...fuzzers-key) https://github.com/bitcoin/bitcoin/pull/17972
< luke-jr>
setpill: the Snaps are just a wrapper around the gitian binaries last I checked - best to verify the latter in that case
< luke-jr>
setpill: if you can use the PPA, that's probably preferable since it's built by Canonical (who also maintains your OS presumably) and compiled specifically for the target platform
< luke-jr>
(of course, building yourself from source is ideal)
< setpill>
luke-jr: the PPA was deprecated because of loss of trust in Ubuntu/Canonical, I am not sure why a Snap would be a good replacement :/
< setpill>
Not that I use Ubuntu, I just saw the Snap Store link on the bitcoincore.org download page and was very surprised
< bitcoin-git>
[bitcoin] instagibbs opened pull request #17974: net: Log to net category for exceptions in ProcessMessages (0.18...bp18_network_exceptions) https://github.com/bitcoin/bitcoin/pull/17974
< instagibbs>
is there any way in the github review lifecycle to preview all the comments you're going to make in one place? I can't seem to find this
< instagibbs>
"preview" button just previews what the final comment is, not all the comments on the code
< achow101>
instagibbs: on the main comments page it should show you all of the comments you are about to make in that review