Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.8.0
-
None
-
None
Description
Currently the hole punch test happens when the Kudu filesystem is created. However, we've seen some cases where users have copied existing LBM instances to new filesystems that didn't support hole punching. Doing the test at open time (or maybe at create and open time) would help detect such cases.
We probably want to add some conditions on this though:
- Skip in on read-only filesystems.
- Skip it in unit tests (unnecessary slowdown?).
Attachments
Issue Links
- is related to
-
KUDU-2536 Make log_block_manager_test_hole_punching work again
- Open