That explains how the bitmap-size should be calculated much better actually in an understandable way, and makes a lot of sense now that it's mentioned. One of those "Oh, duh!" type of descriptions.
Also, good reminder on using an external journal for the main file system, though once it switches over to btrfs that will go out the proverbial window so I'm probably not going to rely on that. While it's still EXT4 it will definitely help though.
Even more than an SSD, storage on the HyperOS is spendy... 1-6 DDR2 RAM DIMMs plus the US$2-300 up-front cost for the chassis + SD and/or CF card for persistant storage since the battery-backup is only to write out the DIMMs to flash, but compared to the US$1650-2100 cost of 15 1.5-2.0TB hard drives it's reasonable as something of a persistant-storage device for a very small block of near-zero-latency storage like the bitmaps I felt.
Are the expected size requirements for the upcoming bad-block tables on par with the dirty-bitmap tables? Larger? Smaller?
Also, by default the write-bitmap is 'dirtied' appropriately before any actual writes occur to the array itself, then a given bit marked clean again after a timeout period, correct?
