# Redwood engine and Directory layer

**URL:** <https://forums.foundationdb.org/t/redwood-engine-and-directory-layer/3084>\
**Category:** Development\
**Tags:** bindings\
**Created:** [December 17, 2021, 9:33am UTC](https://forums.foundationdb.org/t/redwood-engine-and-directory-layer/3084 "2021-12-17T09:33:19Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![SteavedHams](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/steavedhams/32/18_2.png) [@SteavedHams](https://forums.foundationdb.org/u/SteavedHams)\
**Post date:** [December 19, 2021, 10:02am UTC](https://forums.foundationdb.org/t/redwood-engine-and-directory-layer/3084/8 "2021-12-19T10:02:29Z")

</div>

> [@rajivr](#):
>
> Is supporting Directory Layer something that is really needed for FDB 7.0 and beyond with Redwood Engine? If so, what aspects of Directory Layer API and Record Layer’s KeySpace API might users find useful.

When using the Redwood storage engine the main benefit of the Directory Layer becomes the ability to move/rename directories and having smaller keys in network messages (though some of these may eventually use prefix compression).

The main benefit of not using the Directory Layer is avoiding additional reads to resolve directories to their shortened unique prefixes. It is also worth pointing out that without the Directory Layer it becomes easier to move/copy part of the keyspace from one FDB cluster to another, which can be useful for multi-cluster deployments. With the Directory Layer such a move/copy must involve reconciling the likely-different directory → prefix mappings of the two clusters and possibly translating the copied keys to match the destination cluster.

> [@rajivr](#):
>
> How can I try Redwood storage engine with prefix compression today? Does it require building 7.0 from scratch? I tried looking for documentation for this but could not find it.

All releases of FDB 7.0 will have Redwood available for use as a storage engine with the name `ssd-redwood-1-experimental`. This means you can `configure` it as your cluster’s main storage engine (but note the experimental label!) or you can use the new TSS feature to test Redwood against your workload with zero risk to durability, availability, or performance of your FDB cluster.

While Redwood is still marked experimental, in practice it is very stable and performs very well. There are no known bugs, and the code has passed many millions of correctness tests. It is still marked experimental mainly because it is not being used in production anywhere yet, and there are some minor but not-backward-compatible changes being made in it for FDB 7.1.

---

_[View the full topic](https://forums.foundationdb.org/t/redwood-engine-and-directory-layer/3084)._