Details
Description
The definition of the field OmKeyInfo.keyName is ambiguous.
In some of the code, it is the full path to a file; in some, it is just the final part (excluding the path).
I am looking at a cluster where some of the entries in fileTable in its OM db has full path, and some don't.
# ozone debug ldb --db=om.db scan --column_family=fileTable -l -1 --with-keys | less "/-9223372036854561536/-9223372036854561024/-9223372036854525695/433dfbc470b54a0e9a23ed79240c3dc3" -> { "volumeName": "vol1", "bucketName": "bucket1", "keyName": "hbase/data/hbase/meta/1588230740/info/433dfbc470b54a0e9a23ed79240c3dc3", ... "/-9223372036854561536/-9223372036854561024/-9223372036854525695/c3a068821e7544caae7cdbaf9ca1b263" -> { "volumeName": "vol1", "bucketName": "bucket1", "keyName": "c3a068821e7544caae7cdbaf9ca1b263",
Bug: ListStatus request returns incorrect path name, because OzoneListStatusHelper.getStatus() expects the keyName to be just the final part, and prepend the prefix, which is incorrect for the example above.
Attachments
Attachments
Issue Links
- causes
-
HDDS-8312 [Hbase-Ozone] Balancer Doesn't start
- Resolved
- Discovered while testing
-
HDDS-7593 Supporting HSync and lease recovery
- Resolved
- fixes
-
HDDS-8260 hadoop.ozone.om.request.key.OMKeyRenameRequestWithFSO: Rename key failed
- Resolved
-
HDDS-8312 [Hbase-Ozone] Balancer Doesn't start
- Resolved
- is related to
-
HDDS-8657 Remove Clone and make use of copyObject in OmDirectoryInfo and OmKeyInfo
- Resolved
- relates to
-
HDDS-8371 A keyName field in the keyTable might contain a full path for the key instead of the file name
- Resolved
- links to