01:57:41 <alMalsamo> 2022-02-13 01:56:27.674 I Synced 735208/2558182 (28%, 1822974 left, 3% of total synced, estimated 3.0 months left)                                                            
01:57:51 <alMalsamo> 3 months good grief!  >_<
01:58:11 <alMalsamo> Can someone explain the difference between the two percentages, why does it say both 29% and 3%?
03:08:59 <Steven_M> Hi all :-)
07:21:19 <rbrunner> alMalsamo: Your blockchain file currently contains 28% of all blocks.
07:21:33 <rbrunner> From what is left for you to sync beyond those 28%, 1822974 blocks, you synced about 3% of them (thus about 55,000) in your current syncing run.
07:21:47 <rbrunner> This regularly confuses people, but I think it's difficult to find a decidedly clearer message that is still reasonably short ... (I am the one to blame, my code)
08:01:11 <moneromooo> alMalsamo: not too late.
08:08:11 <alMalsamo> moneromooo: Really?  I just kill the process and restart it with the additional switch and it will resume fine?
08:18:59 <moneromooo> Yes.
09:28:49 <alMalsamo> OKay I killed monerod and tried to restart it after remounting my /mnt partition and it totally fails now
09:28:52 <alMalsamo> 2022-02-13 09:28:02.474 W Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid                                                           
09:28:55 <alMalsamo> 2022-02-13 09:28:02.478 E Error opening database: Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid                                   
09:28:58 <alMalsamo> 2022-02-13 09:28:02.480 I Stopping cryptonote protocol...                                                                                                                     
09:29:01 <alMalsamo> 2022-02-13 09:28:02.480 I Cryptonote protocol stopped successfully                                                                                                            
09:29:04 <alMalsamo> 2022-02-13 09:28:02.481 E Exception in main! Failed to initialize core          
09:38:46 <moneromooo> You can try running once with --db-salvage and hope you get lucky.
09:51:20 <alMalsamo> moneromooo: its giving me the same errors :(
09:51:30 <alMalsamo> You said I could kill the process and restart it!  >_<
09:56:33 <moneromooo> Yes, you can.
09:58:42 <moneromooo> Now, you get to delete the chain though.
10:23:57 <alMalsamo> Okay so why am I getting these DB errors?  There is no way to resume I really have to delete and start from scratch?
10:24:18 <alMalsamo> If I can kill the process I would hope it can resume okay like was suggested here...
10:29:43 <rbrunner> Well, if everything is still fully under control, it's much better to use the daemon interactive command "exit" to leave because that just closes everything in a clean way.
10:30:46 <rbrunner> This gives a very reliable resuming.
10:31:14 <alMalsamo> rbrunner: How do I type exit when there is no CLI prompt when I run the monerod process it just shows progress of sync like I was pasting, there is no prompt to enter commands...?
10:31:31 <rbrunner> How do you start it?
10:32:06 <rbrunner> If if shows something on the console usually it just is ready for you to type something as well
10:32:24 <rbrunner> It just does not show any special prompt to welcome you to do so, if you understand what I mean
10:34:00 <rbrunner> Even if it's busy outputting lines you should be able to type "exit" and enter
10:36:11 <alMalsamo> monerod --data-dir /mnt/monero --prune-blockchain --db-salvage
10:36:25 <alMalsamo> Oh I didn't have db-salvage initially
10:36:37 <alMalsamo> I am trying with db-salvage now and it still is broken :(
10:44:31 <rbrunner> Looks like some bad luck then. Yes, if you start that way and see its output in the console, you can also type the "exit" command.
10:47:02 <moneromooo> Why do you have a car accident ? You don't set out to have one, and most rides don't end in an accident. It's just bad luck, and it happens from time to time, unknown cause so far.
10:49:43 <moneromooo> But you could try killing it again after restarting and see if it dies the same way on restart. This would hint that your particular setup is prone to those and might help debug things.
10:50:01 <rbrunner> You mean cases where the daemon terminates / is terminated where it should be able to commit properly but mysteriously isn't?
10:50:54 <moneromooo> I don't know whether the problem is inability to commit properly.
10:52:04 <moneromooo> alMalsamo: what filesystem's on /mnt/monero btw ?
10:58:27 <alMalsamo> moneromooo: NTFS lol whoops
10:59:03 <alMalsamo> FUSE mounted
11:01:09 <rbrunner> That setup may be a tad optimistic :)
11:47:41 <moneromooo> And it'll also explain the extreme slowness.
11:49:40 <moneromooo> Has anyone seen any difficulty desync between nodes in the last, say, year ?
11:50:16 <moneromooo> That is, nodes on the same top height, but with slighly different difficulty values.
11:50:26 <moneromooo> s/height/block/
14:10:08 <selsta> alMalsamo: see https://github.com/monero-project/monero/issues/8144#issuecomment-1021711697
14:11:39 <alMalsamo> selsta: Do you know a tool to benchmark FUSE filesystems vs. in-kernel filesystems?
14:18:26 <selsta> no I don't and monero sync is extremely random io heavy which isn't well captured by benchmark tools
14:23:29 <selsta> moneromooo: as far as I know there haven't been any difficulty desync reports since you have fixed this bug
14:45:46 <moneromooo> OK. I was looking at sync performance again a bit yesterday, and this would be an easy re-win. It was such a rare and devious bug though. Would be a shame to miss a repro.
14:58:04 <selsta> moneromooo: can't you just run this code after the initial sync as a compromise?
14:58:31 <selsta> or otherwise I would just remove it again, it seems fixed at this point
14:59:52 <moneromooo> The code calculates the diff with (1) the incremental cache system and (2) the brute force lookups, and compares. Running it only after initial sync will only catch an issue long after it happened.
15:21:49 <garth> Whatever happened to that guy who was going to do a better statistical approach to the decoy selection algorithm?
15:21:59 <garth> Did that ever come to anything?
15:28:37 <moneromooo> I think that's Rucknium[m] - still around.
15:32:55 <Rucknium[m]> garth: Yes I'm working on it
15:32:55 <Rucknium[m]> https://github.com/Rucknium/OSPEAD
15:33:31 <Rucknium[m]> Do you want to see a draft of the technical specification? (above is just some testing code)
15:50:13 <garth> Sure! I was just curious. The talk you gave (I think on Monero talk) was just super interesting so I’m eager to see how things progress 
16:18:17 <Rucknium[m]> I haven't given any talks like that, so you may be thinking of someone else. I will PM you.
21:54:40 <dell> hi
23:14:55 <narf> hi