Takeru Ohta

> we might be able to use the largest search spaces for those parameters @hvy I think that fANOVA can handle this case with no problems.

@c-bata Thank you for your information! It seems useful.

It is a good idea. I think it may be reasonable to add target host information in `fibers_rpc` (e.g., https://github.com/sile/fibers_rpc/blob/master/src/client_side_handlers.rs#L37 ).

Although it seems a good feature (I also considered this before), there is a difficulty due to the architectural design of frugalos. In the current design, frugalos does not keep...

メリット・デメリットがあるので、PUT_CHECKSUM的なレコードを新設して、ユーザ側で利用するかどうかを選択するようにしても良いのではないかと思いました。 後は、（入れるとしても）チェックサムの計算処理によってI/O処理用のスレッドの実行をブロックしたくはないので、その外側でチェックサムを実行するようにすると良さそうです（一時期、それに近いことをやっていたことがありました）。

この対応良いですね（※ 方針ドキュメントを読んだだけで、まだコードはみていないです）。 パフォーマンス低下に関しては、最低限、オプションでこのモードのON/OFFが切り替え可能になっていれば大丈夫なような気がしました。 (もちろん、実用途に適用する前にはベンチマークを取るのは必須だとは思いますが)

対応方針(案)メモ ============ ストレージフォーマットの互換性を崩さない方式: - delete_rangeのstartおよびendの型をBoundにした版のメソッドを追加 - ただし、内部的にはdelete_rangeに変形して処理する - 例外として `Bound::Unbound` ないし `Bound::Included(最大ID)` がendに指定された場合には、追加で`delete(最大ID)`を内部的に発行する - cannylsのバージョンをv1.0.0に上げるタイミングに合わせて、外部にはBound版のdelete_rangeのみを提供するようにする ### 代替案 - (a) DELETE_RANGEレコードのendの扱いをinclusiveにする - ストレージフォーマットの互換性が崩れるので、フォーマットのメジャーバージョンを上げる必要があり影響が大きい - (b) DELETE_RANGE_INCLUSIVE的なレコードを新設する - 似たようなレコードが複数できることになってしまう - 最大IDがendで指定されることはごく稀だと思われるので、そのためだけに追加するのはやりすぎ感 -...

https://github.com/frugalos/cannyls/issues/7#issuecomment-435043169 は **欠点** が気になるので、代替案の `(b)` 方式の方が良いかもしれない。 かつ、現状の使用状況を仮定して、cannyls-v1のリリースタイミングで、旧DELETE_RANGEレコードは削除してしまう（削除が厳しいなら、レコード読み込み部分に旧DELETE_RANGEを検出したら、新DELETE_RANGEに変換する処理を入れても良いかもしれない）。

これは問題ですね...。 対応としては「アロケータにメモリ位置を解放した通知を行うタイミングを遅らせる」が良さそうに感じました。 (解放依頼はすぐにアロケータに発行せずにジャーナル領域のキューに積んでおいて、unreleased_headの更新タイミングで、永続化されたことが分かっている分に関しては、キューから出して、アロケータに実際の解放依頼を投げる）

👍