use sandbox folder for txhashset validation on state sync

[garyyu]

An improvement on the txhashset validation procedure: use a sandbox folder for new downloaded txhashset files and the validation is based on sandbox folder firstly. The local txhashset will be overwritten ONLY when validation is ok.

The sandbox folder will be cleaned immediately no matter what's the validation result.

[antiochp]

If we are going to introduce a sandbox I think we should separate them more explicitly.
And we should avoid extracting the txhashset a 2nd time post-validation.

[antiochp]

We can just pass either root_dir or sandbox_dir as the first param and we don't need to handle the precedence rule here.

[garyyu]

Thanks @antiochp for the review.

You have header/header_head and header/sync_head/ reading on this open() function, but header/ is at same level as txhashset/ so surely it doesn't exist in sandbox folder.

That's why I keep this first root_dir param.

Could you explain more about why we need put header\ also into the sandbox folder?

			header_pmmr_h: PMMRHandle::new(
				&root_dir,
				HEADERHASHSET_SUBDIR,
				HEADER_HEAD_SUBDIR,
				false,
				None,
			)?,
			sync_pmmr_h: PMMRHandle::new(
				&root_dir,
				HEADERHASHSET_SUBDIR,
				SYNC_HEAD_SUBDIR,
				false,
				None,
			)?,

[garyyu]

Ah, perhaps that rebuild did the job :-)

		self.rebuild_header_mmr(&Tip::from_header(&header), &mut txhashset)?;

[garyyu]

but then what's the best to handle this header/ folder in sandbox?

1. also move to the db root
2. call a rebuild_header_mmr() again after moving the txhashset/ folder

Which one do you prefer? Is the rebuild_header_mmr() a fast or slow processing?

[garyyu]

Tried with moving the header/ folder, but see a lot of Corrupted storage log which could be caused by not-atomic processing on store during txhashset_write processing?

Switch to rebuild_header_mmr() solution now.
And regarding the speed, the rebuilding spent 10 seconds on my slow mac air for current main chain height. not bad.

[antiochp]

Ahh ok.

chain_data/txhashset <- txhashset.zip unzips to here
chain_data/header    <- local data only, not included in the zip file (rebuilt from headers from db)

The original intent was to keep the header dir out the txhashset dir to make it more explicit what originated from txhashset.zip and what was purely built locally.

Maybe we consider making the sandbox dir a couple of levels deep?

So we can have something like -

chain_data/txhashset
chain_data/header

$sandbox_dir/txhashset
$sandbox_dir/header

Would this work?

I don't see any reasons why we would not be able to copy across both the txhashset dir and the header dir on successful validation.
A txhashset will have file references to files under both these dirs so we'd need to be careful with ordering.
i.e. copy them across then reopen the newly updated txhashset.

Edit: rebuild_header_mmr would work but we should not need to do this. Its not based on data from txhashset.zip so is effectively wasted effort as we simply read the headers from the db and rebuild the header MMR a second time this way.

[garyyu]

@antiochp I don't know why, I tried the header dir moving on 2a6182b, but there were a lot of Corrupted storage logs. So I switch to rebuild_header_mmr solution.

[antiochp]

Ran "fast sync" locally and it went flawlessly.
Watched the tmp txhashet dir get used and cleaned up after validation under $TMPDIR.

👍