Good points in both posts, but I think there’s still some unclarity. Absolutely let’s talk about DB and WAL together. By “bluestore goes on flash” I assume you mean WAL+DB? “Simply allocate DB and WAL will appear there automatically” Forgive me please if this is obvious, but I’d like to see a holistic explanation of WAL and DB sizing *together*, which I think would help folks put these concepts together and plan deployments with some sense of confidence. We’ve seen good explanations on the list of why only specific DB sizes, say 30GB, are actually used _for the DB_. If the WAL goes along with the DB, shouldn’t we also explicitly determine an appropriate size N for the WAL, and make the partition (30+N) GB? If so, how do we derive N? Or is it a constant? Filestore was so much simpler, 10GB set+forget for the journal. Not that I miss XFS, mind you. >> Actually standalone WAL is required when you have either very small fast >> device (and don't want db to use it) or three devices (different in >> performance) behind OSD (e.g. hdd, ssd, nvme). So WAL is to be located >> at the fastest one. >> >> For the given use case you just have HDD and NVMe and DB and WAL can >> safely collocate. Which means you don't need to allocate specific volume >> for WAL. Hence no need to answer the question how many space is needed >> for WAL. Simply allocate DB and WAL will appear there automatically. >> >> > Yes, i'm surprised how often people talk about the DB and WAL separately > for no good reason. In common setups bluestore goes on flash and the > storage goes on the HDDs, simple. > > In the event flash is 100s of GB and would be wasted, is there anything > that needs to be done to set rocksdb to use the highest level? 600 I > believe _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |