3 ms·
I'm not a filesystem developer, but assuming the corruption is caused by a race condition in the filesystem driver the difference can come down to many aspects:
by steerablesafe 6y ago
I'm not a filesystem developer, but assuming the corruption is caused by a race condition in the filesystem driver the difference can come down to many aspects:
* Different timings accessing a raw device compared to a virtual drive.
* The presence of the host scheduler can also alter timings.
* CPU configuration on the guest that's not typical on a bare metal (single CPU VM?)
It's not at all obvious that a bug must manifest the same way on a VM than on bare metal, although probably more often than not that's the case. If filesystem testing is also done on VMs then that would explain how this slipped through QC.
- rndgermandude 6y agoSure, there are race bugs that can in theory be affected by things like that. This seems to be a deterministic bug tho. Open "special" file path to an $I30 attribute stream, crash and burn.
- rfoo 6y agoSure, but there are no corruption at all. The bug is, if you write garbage data into a file "name" similar to those holding filesystem internal metadata, the filesystem driver detects this and mistakenly thinks the file could be the real metadata, so it does a consistency check on it, and because it fails consistency check, it sets a "volume needs fsck" flag. Windows (after 18H2) then show an alert. The alert is extremely confusing (it literally says "disk corruption") to the user, hence all the buzz.