> Shashi/Mukul: YCSB / HBase testing
-> without modification it doesn't work as hflush is required.
-> hflush is implemented on a branch
-> a,b,c,d,f workflows are tested so far, without any error
-> basic failover is tested (without YCSB)
-> Jitendra / Clay: open problems / possible solutions are discussed
> Shashi/Matt: Open questions about the Trash feature
> There are technical questions and usability / behavior questions
> o3fs: seems to be easy
> Is it a usability problem to have bucket level Trash directory
with ofs
--> Jitendra: we already have precedent, HDFS + encryption zones
can have similar structure
> Can we enable GDPR + Trash together
--> Seems to be possible, but in that case GDPR delete will be
activated when trash is cleaned
> Implementation question: Using separated trash column-family or
reuse existing delete / key table. Proposed to use a new column-family.
Easier separation, but some additional work (for example with a full
recursive ls)
> Open questions are collected here: https://hackmd.io/@cxorm/B1Hmsd4t8
> Jitendra: What about using Trash bucket with o3fs? (Marton: does
it required volume level write lock instead of bucket level??)
> Do we need ordered keys (timestamp in the key name) to make easier
the work of the eviction thread?
> Quick overview of ofs:
> Quick summary shared about ofs to help the conversation about Trash
feature
> Global view of Ozone namespace
> we don't need to create vol1/bucket1
> importing large keyspace is easier (importing to multiple buckets
instead)
> evolving on a feature branch, will be ready to merge, soon
> see: https://issues.apache.org/jira/browse/HDDS-2665
> see:
https://issues.apache.org/jira/secure/attachment/12987636/Design%20ofs%20v1.pdf
Marton
---------------------------------------------------------------------
To unsubscribe, e-mail: ozone-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: ozone-dev-h...@hadoop.apache.org
