If mass storage were free, then everything would be append-only by default. There would be no excuse to not do this.
A major benefit of append-only is that your writes are always ideal for whatever storage medium. Especially magnetic or tape. Combine append-only with batching of transactions (i.e. across 1-10 milliseconds at a time), and you can write multiple txns per disk I/O operation (assuming txn size < storage block size).
Isn't information retrieval potentially more costly if you have to search over a larger sea of useless blocks. Certainly is the case in my garage+house where I can now store way more than I ever could in previous stages of my life.
The root should be locatable in ~constant time. If you use something like the splay tree, the most recently-used/modified/inserted data remains near the hotter side of the log. There is no linear scanning aside from initial bootstrap in an approach like this.
You can search for some comments I made recently about an append-only database scheme.
doesn't mean everything is permanently etched into stone or written on the blockchain, it just means that "by default" everything you write is written to a new block[1], instead of having to free up old blocks to reuse and keep track of which blocks of storage are available
[1]"block" is just meant as a generic unit of storage, I'm not trying to say anything about actual drive blocks and implementation details
The blocks with those would be scribbled over and invalidated.
Do you know why ASCII 0x7f is DEL? Paper tape is write-once. To indicate a deleted character, it was conventional to punch holes in all bit positions -- 0x7f on a 7-bit punch.
Comments
If mass storage were free, then everything would be append-only by default. There would be no excuse to not do this.
A major benefit of append-only is that your writes are always ideal for whatever storage medium. Especially magnetic or tape. Combine append-only with batching of transactions (i.e. across 1-10 milliseconds at a time), and you can write multiple txns per disk I/O operation (assuming txn size < storage block size).
Isn't information retrieval potentially more costly if you have to search over a larger sea of useless blocks. Certainly is the case in my garage+house where I can now store way more than I ever could in previous stages of my life.
The root should be locatable in ~constant time. If you use something like the splay tree, the most recently-used/modified/inserted data remains near the hotter side of the log. There is no linear scanning aside from initial bootstrap in an approach like this.
You can search for some comments I made recently about an append-only database scheme.
what if you accidentally wrote your private key, photos of your nude boyfriend, or evidence of a crime to your mass storage
Then you would delete it
doesn't mean everything is permanently etched into stone or written on the blockchain, it just means that "by default" everything you write is written to a new block[1], instead of having to free up old blocks to reuse and keep track of which blocks of storage are available
[1]"block" is just meant as a generic unit of storage, I'm not trying to say anything about actual drive blocks and implementation details
Even if it is etched in stone (or laser blasted into crystal), nothing a chisel and a hammer can't undo. :)
The blocks with those would be scribbled over and invalidated.
Do you know why ASCII 0x7f is DEL? Paper tape is write-once. To indicate a deleted character, it was conventional to punch holes in all bit positions -- 0x7f on a 7-bit punch.
excellent point