Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > alt.comp.os.windows-10 > #181716

Re: New reason for Disk Management ("Shrink") not working

From Paul <nospam@needed.invalid>
Newsgroups alt.comp.os.windows-10
Subject Re: New reason for Disk Management ("Shrink") not working
Date 2025-01-25 11:20 -0500
Organization A noiseless patient Spider
Message-ID <vn331d$2tass$1@dont-email.me> (permalink)
References <vn30ds$2sg61$1@dont-email.me> <vn31hd$2snf7$1@dont-email.me>

Show all headers | View raw


On Sat, 1/25/2025 10:55 AM, Alan K. wrote:
> On 1/25/25 10:36 AM, Paul wrote:
>> I was experimenting with a hard drive the other day,
>> a 4TB one, and making the C: drive really large.
>> This was to counter a complaint from some software
>> "insufficient space to..." type error.
>>
>> So anyway, I could see a green stripe of material about
>> half way out on the disk. I figured, no problem,
>> if I want to shrink the disk, that material will move
>> out of the way for me.
>>
>> It didn't.
>>
>> I got an error, that said the material could not be moved,
>> and it was different than the usual material problem. It was
>> traceable to $BADCLUS, a cluster marked off by the file
>> system driver. Apparently, the SMART log reported a
>> series of "UDMA CRC errors". These are errors on the
>> packets on the SATA cable, causing the packets to be
>> retransmitted. That's not a conventional data CRC as such.
>> Yet, the software decided that this constituted a bad cluster,
>> so the area on the disk was marked off.
>>
>> There is a option in CHKDSK, to verify bad clusters, but this
>> in fact, scans the entire partition again, as if doing a /r .
>>
>> This would check for errors, and bad clusters.
>>
>>     chkdsk /f /r  C:     # Fix structural errors, read-scan all clusters to verify they are working
>>                          # Mark off new bad clusters. Do not verify any existing bad clusters.
>>
>>     chkdsk /b     C:     # This seemingly does the same thing, but can turn bad clusters into good clusters.
>>                          # If a cluster was "flagged by mistake", this can undo it.
>>
>> On a large disk, this can take hours to complete (either command).
>>
>> When the /b run completed, it reported
>>
>>     "Removing 1 clusters from the Bad Clusters File."
>>
>> and that is what I was hoping would happen on the /b run.
>>
>> I went back to Disk Management, and I still could not shrink the volume.
>> It was still reporting there was a problem with the same issue as
>> previously.
>>
>> On a hunch, I booted a Windows 7 disk, cabled up the affected drive,
>> and did a regular CHKDSK on the partition in question. I know at this
>> point, there is nothing wrong with any clusters, so there is no need to
>> do an hours-long scan yet again.
>>
>>     chkdsk /f K:         # Windows 7 CHKDSK (of the second disk drive affected partition)
>>
>> and finally, after this, the Shrink menu started working again in
>> Disk Management. Presumably this is related to Windows 7
>> correcting $BITMAP-type issues. (W10/W11 don't handle $BITMAP
>> properly on partitions any more, leaving data at rest in an
>> indeterminate state.) Windows 7 cares about the $BITMAP, and
>> fixed it up for me.
>>
>> Disk is now back to normal again. The shrink completed (2TB partition down
>> to 200GB) with no trouble at all. When a partition starts small, you make
>> it huge, then there won't be a problem to make it as small as it was at first.
>> Except if there is a bad cluster in there (a cluster flagged as bad
>> while the file system was running).
>>             _________________________________________________
>>            /                                                 \    4096 byte
>>           X   512   512   512   512   512   512   512   512   X   cluster on
>>            \              XXX                                /    OS C: partition
>>             ------------------------------------------------
>>
>>             If any sector is bad, the cluster is marked bad.
>>             The "cluster" is a unit of storage in NTFS.
>>
>>     Paul
>>
> More reason to keep a spare Win7 machine /disk around huh.
> 

If you have a Windows 7 Installer DVD, you should be able to
use the Troubleshooting section and the Command Prompt window,
to do the same thing. I've run CHKDSK from there before, as
an option.

*******

The command line options for CHKDSK, do not have to be
the same for all version. Some of the versions of
CHKDSK have a couple additional options. And on occasion,
those really do something.

Do not cable up modern disks to Windows XP. That's "not recommended" :-)
For this sort of work, Windows 7 is a good option. A Windows 7 boot
drive, or a Windows 7 installer DVD troubleshooting section.

While all the OSes are nominally compatible with NTFS 3.1 API,
they're not really the same thing. And you can see this during
your Win7 CHKDSK run. The behavioral change to $BITMAP for example,
that caused Macrium to have to emergency-patch their software.
Macrium will show some red text and "error 9" or so, if it checks
the data at rest and finds something out-of-spec. And it started
throwing the error 9 and refusing to do backups, after Microsoft
modified $BITMAP behavior. That was fixed  around 6.3.1865 or so.
Any version 7 or version 8, should be fine for W10/W11.

Other companies have had to emergency-patch their stuff. VirtualBox
had to put out a series of patches, while Microsoft kicked its
ass around the corner :-) I thought this pretty funny at the time,
imagine working at your little software company and having to
look over your shoulder all the time. Programs like VirtualBox,
reach into the Guest and "interact" with it. Someone at VirtualBox
was muttering something about "number of parameters on a certain
kernel call got changed". You'd be surprised what happens under
the covers, on your computer. Why does it ever work ??? :-)

   Paul

Back to alt.comp.os.windows-10 | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

New reason for Disk Management ("Shrink") not working Paul <nospam@needed.invalid> - 2025-01-25 10:36 -0500
  Re: New reason for Disk Management ("Shrink") not working "Alan K." <alan@invalid.com> - 2025-01-25 10:55 -0500
    Re: New reason for Disk Management ("Shrink") not working Paul <nospam@needed.invalid> - 2025-01-25 11:20 -0500
    Re: New reason for Disk Management ("Shrink") not working Jim <noreply@ghyhgtgfrde.com> - 2025-01-26 02:06 +0000
      Re: New reason for Disk Management ("Shrink") not working "Carlos E.R." <robin_listas@es.invalid> - 2025-01-26 03:29 +0100
      Re: New reason for Disk Management ("Shrink") not working Paul <nospam@needed.invalid> - 2025-01-25 23:14 -0500
  Re: New reason for Disk Management ("Shrink") not working "Carlos E.R." <robin_listas@es.invalid> - 2025-01-26 03:31 +0100
    Re: New reason for Disk Management ("Shrink") not working Paul <nospam@needed.invalid> - 2025-01-25 22:06 -0500
      Re: New reason for Disk Management ("Shrink") not working "Carlos E.R." <robin_listas@es.invalid> - 2025-01-26 13:54 +0100

csiph-web