What you've proposed is simply a "CTR-then-ECB" over the plaintext. Just a composition of two common cipher modes.
This "double cipher" scheme will fail IND-CPA from your reuse of IV's as the encryption oracle in this case must not only take an arbitrary attacker's "messages" but also use whatever "IV's" they choose to specify as well (since the encryption oracle isn't always generating a new one at random).
So, for example, if they wish to decrypt some given block of ciphertext $c$, they can simply keep feeding "guesses" $p_1, p_2,\ldots$ into your encryption oracle with the known IV (e.g., derived from the disk location) of block $c$. Note that since user plaintexts don't usually have a high degree of entropy, this can be a problem.
Now, you might say, for example, that the encryption oracle might not take in an IV chosen by the attacker, but will just use whatever IV is predefined for some presently free/unused blocks specially reserved for the attacker for an IND-CPA challenge. In other words, the attacker cannot choose the IV that will be used. Since currently user-occupied disk blocks are not modified nor have their specific IV's used, this might not seem like a problem. And it might seem therefore that current "user data" is safe (even if the user modifies) for now.
But -- as I mentioned before, user plaintexts often have a low degree of entropy. An attacker could just spam the presently free locations on your disk to build a rainbow table of possible user plaintexts that could eventually take up the space of the presently free blocks (that are free and therefore available for attacker use). What happens if the user saves some more data on their machine, and those free locations must be written to? What happens if a user copies an existing file to a different location? (even with some modifications, like myData1.txt copied over to a myData2.txt)
The attacker can read the encrypted disk at some later time and see that some previously free / attacked locations have now have user-modifications in them. Perhaps they can run this new ciphertext offline through their previously-constructed rainbow tables that the disk encryption oracle helped them to create earlier (for those block locations)!
And what if a user deletes some data somewhere? Perhaps the attacker knows the previous ciphertext from the block locations that now just opened up, and might use them to run a rainbow table against the encryption oracle to find out what was originally in them.
Or simply copy the user's old deleted ciphertext into that free location as the attacker's own and ask the system to decrypt it!
Your "CTR-then-ECB" is for fine for user data in block locations that are never freed up nor were ever attacked prior. But according to Disk Encryption Theory your free and unused blocks are subject to attack anytime, and it's not unreasonable for a user to write data to previously unused block locations (which may have been attacked) nor free up previously used locations and thus make them ripe for attack.
To circumvent this, we can simply re-encrypt everything in a sector with a new random IV for the sector every time something changes, which is itself stored somewhere in the sector for a small size overhead of 16 bytes. The only case when we might not have to re-encrypt everything in the sector and that is if a file there has been modified without changing its size or block location "range" on disk -- in that case, the attacker might know which blocks have been modified, but unless they had an opportunity to attack those block earlier back when they were free before, they won't be able determine the actual corresponding plaintext nor what the plaintext changes were.
Note that in Disk Encryption Theory the attacker may have quite a few more capabilities than what an average consumer of disk encryption may envision. For example, the threat/attack model regular consumers might envision might be limited to just some attacker trying to decrypt a lost or stolen device, or even a government agent or border control officer requesting to inspect these.
In such cases, assuming the device is simply turned off / shut down at the time, then even a single pass of AES-CTR with a static but unique IV per block location would suffice. And entire sectors need not be re-encrypted for single 16-byte block changes either.
So, in other words, in such "restricted scenarios" wherein which the attacker has zero access to your encryption/decryption oracle, the only additional "protection" offered by your extra ECB step is simply preventing a known plaintext attack from recovering any new user data that overwrote the previously compromised blocks.
But, nonetheless, all of this still depends on how much you "weaken" the threat model and capabilities of your proposed attacker(s).