Raid 1 info needed

I have two 2TB drives that I have put into a software Raid 1 assembly under
Windows 10. I have noticed that every time I have to reboot that one of the
two drives then goes into an extended 97% write mode. Sometimes this mode
will last for more than 24 hours. When I look with Resource Monitor the
only process that shows that much activity is System.
Am I doing something wrong by allowing Windows to handle everything during
a reboot. Is there some command that will ensure that the two disks are
synced during a shutdown cycle?

"Tim" wrote in message
.131...
I have two 2TB drives that I have put into a software Raid 1 assembly under
Windows 10. I have noticed that every time I have to reboot that one of
the
two drives then goes into an extended 97% write mode. Sometimes this mode
will last for more than 24 hours. When I look with Resource Monitor the
only process that shows that much activity is System.
Am I doing something wrong by allowing Windows to handle everything during
a reboot. Is there some command that will ensure that the two disks are
synced during a shutdown cycle?

If you let me put my balls in your mouth,
I will finger your ass while I jerk your dick.

Tim wrote:
I have two 2TB drives that I have put into a software Raid 1 assembly under
Windows 10. I have noticed that every time I have to reboot that one of the
two drives then goes into an extended 97% write mode. Sometimes this mode
will last for more than 24 hours. When I look with Resource Monitor the
only process that shows that much activity is System.
Am I doing something wrong by allowing Windows to handle everything during
a reboot. Is there some command that will ensure that the two disks are
synced during a shutdown cycle?

I've been trying to translate this into techie stuff.

Try looking in Disk Management, for evidence of what
flavor of software is involved.

When I start the Win10 installer, there is no option
for setting up a RAID that I can see.

For the longest while, Windows has had Veritas
"dynamic disk". Which allows non-OS drives to
support span, strip, mirror, etc. These would be
accessible in Disk Management, for application to
one or more disks.

The old Tomshardware recipe for RAID 5, maybe that
was actually Dynamic Disk too, as files like
dmadmin were involved. If you check the ownership
of the dmadmin file on Windows, it's Veritas branded.

So lets review.

Win10
1) Dynamic disk (mirror) - not for C:
2) Storage Spaces (likely similar) - not for C:

So this rebuilding that's going on, could be
one of those two.

Hardware RAID allows mirroring of C: , and needs
a RAID driver early in the install perhaps. Exceptions
might be some flavors of Intel RAID, for which IASTORV
in the OS will work at T=0. Later OSes have a different
name for that (not RST either, the built-in one
had some other name).

*******

You can run

winver

to get the OS version you are running.

Then, document for us, how many drives,
what the drives have on them, and so on.
For example, here I'm trying to clarify that
my C: is not on the mirrored pair.

+-----+-----------------+-----------+
| MBR | System Reserved | C: |
+-----+-----------------+-----------+

+-----+-----------------------+
| MBR | Drive #1 | \
+-----+-----------------------+ \
\___ RAID materials
+-----+-----------------------+ /
| MBR | Drive #2 | /
+-----+-----------------------+

If a volume goes offline for even an instant,
that will cause a mirror to rebuild. You would want
to find a log entry that documents what just
happened.

Maybe Event Viewer has an entry for the
errant subsystem. And you can do your
best to describe the setup, so someone
can comment. There's at least one or two
people here with IT experience (not me).

Paul

Paul wrote in news1m8ma$18l$1@dont-
email.me:

Tim wrote:
I have two 2TB drives that I have put into a software Raid 1
assembly
under Windows 10. I have noticed that every time I have to
reboot
that one of the two drives then goes into an extended 97%
write mode.
Sometimes this mode will last for more than 24 hours. When I
look
with Resource Monitor the only process that shows that much
activity
is System. Am I doing something wrong by allowing Windows to
handle
everything during a reboot. Is there some command that will
ensure
that the two disks are synced during a shutdown cycle?


Try looking in Disk Management, for evidence of what
flavor of software is involved.

Disk Management says the drives are Dynamic Disks, and are
currently resyncing.

You can run

winver

to get the OS version you are running.


Windows 10 Professional ver 1607 build 14393.447


Then, document for us, how many drives,
what the drives have on them, and so on.
For example, here I'm trying to clarify that
my C: is not on the mirrored pair.

+-----+-----------------+-----------+
| MBR | System Reserved | C: |
+-----+-----------------+-----------+

+-----+-----------------------+
| MBR | Drive #1 | \
+-----+-----------------------+ \
\___ RAID materials
+-----+-----------------------+ /
| MBR | Drive #2 | /
+-----+-----------------------+


Your diagram matches my system. Drive D: is the Raid 1 drive,
which consists of two 2TB disks. The have various kinds of data
stored on them.


If a volume goes offline for even an instant,
that will cause a mirror to rebuild. You would want
to find a log entry that documents what just
happened.

Maybe Event Viewer has an entry for the
errant subsystem. And you can do your
best to describe the setup, so someone
can comment. There's at least one or two
people here with IT experience (not me).

Paul

The only thing of interest I found in the Event Logs as a series
of messages as follows:

Volume Windows 10 System (\Device\HarddiskVolumeShadowCopy812)
is healthy. No action is neededVolume Windows 10 System
(\Device\HarddiskVolumeShadowCopy812) is healthy. No action is
needed

With the HarddiskVolumeShadowCopynnn increasing by one for every
entry. This started after I rebooted the system 23 hrs ago.

Tim wrote:
Paul wrote in news1m8ma$18l$1@dont-
email.me:


+-----+-----------------+-----------+
| MBR | System Reserved | C: |
+-----+-----------------+-----------+

+-----+-----------------------+
| MBR | Drive #1 | \
+-----+-----------------------+ \
\___ RAID materials
+-----+-----------------------+ /
| MBR | Drive #2 | /
+-----+-----------------------+


Your diagram matches my system. Drive D: is the Raid 1 drive,


The only thing of interest I found in the Event Logs as a series
of messages as follows:

Volume Windows 10 System (\Device\HarddiskVolumeShadowCopy812)
is healthy. No action is neededVolume Windows 10 System
(\Device\HarddiskVolumeShadowCopy812) is healthy. No action is
needed

With the HarddiskVolumeShadowCopynnn increasing by one for every
entry. This started after I rebooted the system 23 hrs ago.

Do you have System Restore enabled for the RAID array volume ?
Try disabling it on the RAId volume. If desperate, disable
it on C: too.

Because it mentions "ShadowCopy", I assume part of this
puzzle is VSS, which is part of making shadow copies.

Paul

Paul wrote in news

Do you have System Restore enabled for the RAID array volume ?
Try disabling it on the RAId volume. If desperate, disable
it on C: too.

Because it mentions "ShadowCopy", I assume part of this
puzzle is VSS, which is part of making shadow copies.

Paul

System Restore is only enabled for the C: drive.

At his time the resync is still running, almost 48 hours after the last
reboot. How long should it take to resync two 2TB drives, both of which are
Sata 3?

On 11/29/2016 11:25 PM, Tim wrote:
I have two 2TB drives that I have put into a software Raid 1 assembly under
Windows 10. I have noticed that every time I have to reboot that one of the
two drives then goes into an extended 97% write mode. Sometimes this mode
will last for more than 24 hours. When I look with Resource Monitor the
only process that shows that much activity is System.
Am I doing something wrong by allowing Windows to handle everything during
a reboot. Is there some command that will ensure that the two disks are
synced during a shutdown cycle?

I think one of the problems with using non-RAID disks in a RAID system
is that any little hiccup can send the two mirrors out of sync. Drives
designed for RAID have longer time-outs enabled allowing them enough
time to recover from random delays that can occur between two synced up
disks. Examples of RAID-aware disks are WD Red and Seagate NAS disks.

Yousuf Khan

Yousuf Khan wrote:
On 11/29/2016 11:25 PM, Tim wrote:
I have two 2TB drives that I have put into a software Raid 1 assembly
under
Windows 10. I have noticed that every time I have to reboot that one
of the
two drives then goes into an extended 97% write mode. Sometimes this mode
will last for more than 24 hours. When I look with Resource Monitor the
only process that shows that much activity is System.
Am I doing something wrong by allowing Windows to handle everything
during
a reboot. Is there some command that will ensure that the two disks are
synced during a shutdown cycle?

I think one of the problems with using non-RAID disks in a RAID system
is that any little hiccup can send the two mirrors out of sync. Drives
designed for RAID have longer time-outs enabled allowing them enough
time to recover from random delays that can occur between two synced up
disks. Examples of RAID-aware disks are WD Red and Seagate NAS disks.

Yousuf Khan

Needing TLER for hardware RAID is probably true.

With Software RAID, the setup should be as tolerant
as regular drives are. Since the RAID is built on
top of physical services provided on a per-disk basis.

It's called a logical disk manager for a reason.
It doesn't tinker at that low a level.

Now if I can only find actual *info* on the Win10
version of Dynamic Disk.

I've set up a VM with Win10 and two virtual drives
set up as a mirror. The disk performance graph shows
disk activity on the two disks, in a stairstep fashion.
And the numeric display shows 0 bytes/sec read and
0 bytes/sec write. Which is cool and all, but quite
illogical. It means the disks are busy, underneath
the LDM level. And there are no data files on the
partition yet. That would never stop mirroring activity,
if that's what was actually going on.

My Win10 VM is now in the process of crashing or hanging,
leaving me plenty of time for other hobbies :-) Can't
control-alt-delete it, hit it with a hammer. Could power
off the VM, but then will never know what happened. VM
still answers "ping", so it's not really dead, just
"sulking".

Paul

Tim wrote:
Paul wrote in news
Do you have System Restore enabled for the RAID array volume ?
Try disabling it on the RAId volume. If desperate, disable
it on C: too.

Because it mentions "ShadowCopy", I assume part of this
puzzle is VSS, which is part of making shadow copies.

Paul

System Restore is only enabled for the C: drive.

At his time the resync is still running, almost 48 hours after the last
reboot. How long should it take to resync two 2TB drives, both of which are
Sata 3?

I don't think it is resync.

Here are a couple captures from my test VM.

https://s17.postimg.org/xry0bz45b/dy...r_activity.gif

There is some kind of activity, that uses a "percentage"
of the disk. It grows and diminishes.

The disk transfer rate shows nothing (in the bottom one, where
I happen to be monitoring E: at the time). Which suggests that
the level this activity happens at, is below Logical Disk Management.
It might be something physical. Who knows. It just has a weird
recording in Task Manager.

There is also currently a bug with external USB hard
drives showing as RAW.

And there used to be problems with SATA link power states
in past OSes. Sometimes the LED lights up and it's not
actually doing stuff to the platters. Just abusing the
interface for some reason.

It's pretty hard to tell the difference between
continuous write on a hard drive (i.e. sequential
transfer at full speed), versus just sitting there.
One way to detect the difference would be temperature
or power consumption. If it was actually using the
disk, the disk might be a bit warmer than when it is idle.
That's not exactly a good method, but there's not much
else to go on.

While NTFS has "robustness" features (the running of CHKDSK
in the background), I don't think it's related to that
either. As my E: disk is empty. There's no files on it
at present.

Paul