thanks Matt, the d4n filter is currently storing all of the object's xattrs in the redis directory, so i wasn't sure we needed them in the cache backend too. it sounds like we don't actually want the directory to store those we're trying to decide what representation to use for the redis cache backend. if we only store data in a redis key, we can use SETRANGE/GETRANGE to operate on ranges. if we include object attributes in the same key, i think we have to use key/value interfaces like HSET/HGET instead. so if the cache needs to do both, we probably want each object to use a different redis key for its data and metadata On Tue, Aug 8, 2023 at 12:44 PM Matt Benjamin <mbenjami(a)redhat.com> wrote: uniquely stores all of what RGW considers attributes. Just "it's own attributes" (attributes relevant to cache operation and strategy; e.g., data location, hit rates, anything else that eventually becomse part of the cache workflow), so far as I know. I think other attributes such as user metadata should be stored on the data cache. wrote: Driver. He was under the impression that the D4N directory should be storing object metadata (and attributes) while the Cache Driver should be storing data only. directory-related operations, which is why S3 attributes like bucket size, mtime, and others are not added to the object's directory entry. Dan has also mentioned the prospect of moving SAL attributes into the directory rather than the cache backend; so this is worth discussing in more detail. let me know.