bluestore 流程解析

1.整体流程

 

bluestore 流程解析_第1张图片

图片发自简书App

 

 

图中展示了流程中的关键路径及涉及到的线程与队列。下面详细阐述工作流程。

重点关注:状态切换;kv存储数据的GC时机

1.1 queue_transactions

queue_transactions是store统一的入口,各个存储引擎如filestore、kvstore、bluestore都得实现这个入口。在queue_transactions里先初始化transaction(初始化状态为STATE_PREPARE),然后在_txc_add_transaction根据操作码的类型进行不同处理,将其放到transaction里,前一篇文章里的I/O映射逻辑就是根据操作码OP_WRITE在BlueStore::_write里进行处理。BlueStore::_write –> BlueStore::_do_write –> (_do_write_small/_do_write_big) –> _do_alloc_write 分配空间,如果采用aio就会调用bdev->aio_write准备aio的结构,放在pending_aios里,如果不是aio就直接pwrite(如果是非direct的还需要sync)。

 

1.2 STATE_PREPARE

_txc_state_proc里就是状态机的处理逻辑,根据所处的状态进行不同阶段的处理。起始状态是STATE_PREPARE,在这个状态下回检查是否还有未完成的aio,如果有就将状态置为STATE_AIO_WAIT,并调用_txc_aio_submit进行处理,否则就直接进入到下一个状态STATE_AIO_WAIT的处理。

 

在_txc_aio_submit里就是就是调用bdev->aio_submit –> KernelDevice::aio_submit –> io_submit将aio提交到内核进行处理(注:目前支持KernelDevice和NVMEDevice,这里以KernelDevice为例)。

 

使用linux Aio时,将I/O提交后,当内核处理完成后会通知到用户态,一种方式是使用eventfd,将其注册到epoll里,当内核处理I/O完成后会触发eventfd的事件从而进行处理;另外一种方式是用一个单独的线程,轮询调用io_getevents去获取完成的事件。在bluestore里采用的是第二种方式,对应的线程是KernelDevice::_aio_thread,当I/O处理完后会调用回调函数aio_cb进行处理(这个回调函数是在bluestore启动时创建KernelDevice设置的),在aio_cb中调用_txc_aio_finish –> _txc_state_proc,从而进入到下一个状态STATE_AIO_WAIT的处理。

 

1.3 STATE_AIO_WAIT

在这个状态里是调用_txc_finish_io进行处理,会将状态设置成STATE_IO_DONE。因为aio的完成可能是乱序的,有可能后提交的I/O先完成,但是需要保证kv事务的顺序性。bluestore里通过OpSequencer来保证kv事务的顺序性(在_txc_create里会将新的txc放到osr->q里,即q.push_back。在_osr_reap_done里从osr->q里挨个剔除完成的。),在_txc_finish_io里就是实现通过OpSequencer来保证每个事务在处于某个状态时,这个事务之前的事务也必须在这个状态,即使某个事务的I/O先完成,也得等到它之前的事务的I/O也完成后才能进入到下个状态的处理。

做了这个保证后,再对按序对STATE_IO_DONE状态的事务调用_txc_state_proc进入下一个状态的处理。

 

1.4 STATE_IO_DONE

进入这个状态后,会设置下个状态为STATE_KV_QUEUED,然后会根据bluestore_sync_transaction和bluestore_sync_submit_transaction这两个配置参数的组合作不同的处理:

1)bluestore_sync_transaction为true:表示同步提交kv到rocksdb并持久化,对应调用_txc_finalize_kv后再调用db->submit_transaction,即rocksdb::Write并设置rocksdb::WriteOptions.sync=true;

2)bluestore_sync_transaction为false,bluestore_sync_submit_transaction为true:表示将kv提交到rocksdb,但是不sync,也就是没有落盘,对应调用_txc_finalize_kv后再调用db->submit_transaction_sync,即rocksdb::Write,但rocksdb::WriteOptions.sync=false;

不管采用何种处理方式,最后都会将事务放到kv_queue里,然后通过kv_cond通知_kv_sync_thread。

 

1.5 _kv_sync_thread处理kv_queue

_kv_sync_thread线程里就是处理kv_queue和wal_cleanup_queue里的事务。按照流程,这一步走到从kv_queue里取事务进行处理的过程。处理的时候是将kv_queue替换给kv_committing,然后后续对kv_committing进行处理。

当bluestore_sync_transaction和bluestore_sync_submit_transaction都为false时(也就是在前一个状态里没做事务相关处理,直接放到kv_queue里了),会遍历kv_committing里的事务,调用_txc_finalize_kv将空间分配释放相关的元数据在kv事务进行处理(如设置key、删除key等),然后db->submit_transaction将kv提交到rocksdb,但是没有落盘。

 

然后都会调用db->submit_transaction_sync来进行提交并刷盘的动作,这样即使在1.4那一步已经提交sync了,这里也会多做一次,以确保不管前面是没提交、只提交了没sync、提交并sync了的,到了这一步操作后事务都落盘了。

 

对于每个处理完的事务,都会调用_txc_state_proc进入到下一个状态STATE_KV_QUEUED的处理。

 

1.6 STATE_KV_QUEUED

设置状态为STATE_KV_DONE,然后调用_txc_finish_kv处理onreadable、oncommit回调,就是将回调放到finisher queue里,触发finisher thread去进行回调的处理(即如果各个副本都处理完成,就会发送对应的响应给客户端)。然后直接进入到STATE_KV_DONE状态的处理。

 

1.7 STATE_KV_DONE

如果没有wal事务要处理,就直接设置状态为STATE_FINISHING,然后跳出此处处理,在下一次处理到该事务时判断到状态为STATE_FINISHING,从而进行完成的一些处理。

 

下面主要介绍有wal的情况,之前一篇文章讲过当有覆盖写的时候就会进行wal,设置状态为STATE_WAL_QUEUED,然后根据配置参数bluestore_sync_wal_apply有两种处理方式:

1)当bluestore_sync_wal_apply为false,就把事务放到wal_wq中(会触发WALWQ threads去处理),结束此次处理;

2)当bluestore_sync_wal_apply为true时,直接调用_wal_apply进行处理;

在_wal_apply中会设置状态为STATE_WAL_APPLYING,然后遍历wal事务中的op,调用_do_wal_op进行处理,在_do_wal_op里调用bdev->aio_write准备aio的结构,放在pending_aios里,如果不是aio就直接pwrite(如果是非direct的还需要sync)。

当wal事务中的op都处理完后,就会调用_txc_state_proc进入到下一个状态的处理。

 

1.8 WALWQ threads

上面说到在bluestore_sync_wal_apply为false时,wal事务直接放到wal_wq中,交由WALWQ的线程池来处理。在这个线程池里也是调用_wal_apply进行处理,具体在上面已经说过了。处理完调用_txc_state_proc进入到下一个状态STATE_WAL_APPLYING的处理。

 

1.9 STATE_WAL_APPLYING

在这个状态下回检查是否还有未完成的aio,如果有就将状态置为STATE_WAL_AIO_WAIT,然后调用_txc_aio_submit提交I/O到磁盘,并结束此次处理。否则就判断是否满足后续状态,如果是就进行处理,如果不是就结束。

 

在KernelDevice::_aio_thread,当I/O处理完后会调用回调函数aio_cb进行处理,在aio_cb中调用_txc_aio_finish –> _txc_state_proc,从而进入到下一个状态STATE_WAL_AIO_WAIT的处理。

 

1.10 STATE_WAL_AIO_WAIT

在这个状态下,调用_wal_finish,设置状态为STATE_WAL_CLEANUP,然后放到wal_cleanup_queue中,通知_kv_sync_thread去处理。

 

1.11 _kv_sync_thread处理wal_cleanup_queue

处理的时候是将wal_cleanup_queue替换给wal_cleaning,然后后续对wal_cleaning进行处理。在1.5节里已经介绍过kv_sync_thread对kv_queue的处理,其实_kv_sync_thread在每次处理时都是同时处理kv_queue和wal_cleanup_queue里的事务,只不过本文是按照逻辑处理流程才分开描述的。

 

对于wal_cleanup_queue里的事务,也是调用_txc_finalize_kv将空间分配释放相关的元数据在kv事务进行处理(如设置key、删除key等),然后在接下去的db->submit_transaction_sync中统一提交kv到rocksdb并sync落盘。这次submit_transaction_sync的调用对于kv_queue和wal_cleanup_queue中事务都是一起生效的。

 

在处理完成后,对于wal_cleanning中的事务都会调用_txc_state_proc进行下一个状态的处理。

 

1.12 STATE_WAL_CLEANUP

在这个状态里就是设置状态为STATE_FINISHING,然后直接进入STATE_FINISHING状态的处理。

 

1.13 STATE_FINISHING

调用_txc_finish进行一些结束状态的处理。

 

2.总结

从上面的流程分析可以知晓,一个I/O在bluestore里经历了多个线程和队列才最终完成,对于非WAL的写,比如对齐写、写到新的blob里等,I/O先写到块设备上,然后元数据提交到rocksdb并sync了,才返回客户端写完成(在STATE_KV_QUEUED状态的处理);对于WAL(即覆盖写),没有先把数据写块设备,而是将数据和元数据作为wal一起提交到rocksdb并sync后,这样就可以返回客户端写成功了,然后在后面的动作就是将wal里的数据再写到块设备的过程,对这个object的读请求要等到把数据写到块设备完成整个wal写I/O的流程后才行,代码里对应的是_do_read里先o->flush()的操作,所以bluestore里的wal就类似filestore里的journal的作用。



作者:620T
链接:https://www.jianshu.com/p/880033db42a7
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

你可能感兴趣的:(bluestore 流程解析)