3 ms·
Q about a related use case: Can I use tiered storage (e.g., SSD cache in front of a HDD with, say, dm-cache), or an md-based approach like Discord's, to success
by madars 4y ago
Q about a related use case: Can I use tiered storage (e.g., SSD cache in front of a HDD with, say, dm-cache), or an md-based approach like Discord's, to successfully sync an Ethereum node? Everyone says "you should get a 2TB SSD" but I'm wondering if I can be more future-proof with say 512 GB SSD cache + much larger HDD.
- pas 4y agoSure, you might want to look into bcache or bcachefs.
- Nextgrid 4y agoI'm not familiar with what Ethereum requires for its syncing operation. If it's a sequential write (by downloading the entire blockchain), you will still be bottlenecked by the throughput of the underlying disk. If it's sequential reads (in between writes), the reads can be handled by the cache if the location is local enough to the previous write operation that it hasn't been evicted yet. If it's random unpredictable reads, it's unlikely a cache will help unless the cache is big enough to fit the entire working dataset (otherwise you'll get a terrible cache hit rate as most of what you need would've been evicted by then) but then you're back at your original problem of needing a huge SSD.
- brobinson 4y agoIf your hardware sucks, try Akula instead of geth/erigon. It can supposedly sync on spinning rust with low IOPS. Unless you're running a full archive node, you don't need 2tb. My geth dir is under 700gb. Do a snap sync then turn on archive mode if you only need data moving forward from some point in time.