3 ms·

> I spent a lot of time with this yesterday analysing it in a VM and I couldn’t find any cases where on reboot it caused chkdsk to actually take any actions. It

by shakna 6y ago

> I spent a lot of time with this yesterday analysing it in a VM and I couldn’t find any cases where on reboot it caused chkdsk to actually take any actions. It always found the file system clean. That is very frequently the case with these kinds of filesystem bugs. You need actual hardware, not a VM. FWIW, it does seem to be reproducible on hardware.

uncledave 6y ago
I’ve just tried it on my native T470 backup machine quick and same result. No action for chkdsk. This was a single test so the veracity of the outcome is somewhat debatable.
rndgermandude 6y ago
I don't see why this bug would work any different in a VM than on a real bare-metal OS or disk? It's an NTFS issue, i.e. a software issue. NTFS doesn't care if the underlying disk is virtual or bare metal. In fact, it kinda runs on virtual disks already even on bare metal, i.e. disk partitions (maybe even with a layer of encryption in between). There could be potential issues of course where you could get NTFS to trigger some hardware bugs, but that doesn't seem to be the case here, instead it is about accessing NTFS $I30 attributes.
- 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 ago
    Sure, 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 ago
    Sure, 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.

by shakna 6y ago

uncledave 6y ago

I’ve just tried it on my native T470 backup machine quick and same result. No action for chkdsk. This was a single test so the veracity of the outcome is somewhat debatable.

rndgermandude 6y ago

I don't see why this bug would work any different in a VM than on a real bare-metal OS or disk? It's an NTFS issue, i.e. a software issue. NTFS doesn't care if the underlying disk is virtual or bare metal. In fact, it kinda runs on virtual disks already even on bare metal, i.e. disk partitions (maybe even with a layer of encryption in between). There could be potential issues of course where you could get NTFS to trigger some hardware bugs, but that doesn't seem to be the case here, instead it is about accessing NTFS $I30 attributes.

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 ago
  Sure, 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 ago
  Sure, 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.