RE: KB913648 Volume Shadow Copy Service update

Hi ,

VOLSNAP.SYS driver used to take and manage volume snapshots requires paged
pool memory to keep track of previous versions of files. The amount of
paged pool used for a snapshot with sufficiently many files touched on it
is about 1 byte per file. Whenever a new block of 65536 files is touched,
65536 bytes of paged pool are allocated. However, this also all depends on
how many snapshots are currently mounted.

This works out so that a server with 2 million files or less and 64
snapshots will always stay below the recommended 128 MB of paged pool
threshold. A server with more files might be able to manipulate the
snapshot storage size so that fewer than 64 snapshots are kept.

Solution:

Reduce the amount of snapshot storage used for all volumes so that your
total paged pool usage stays within limits. You can use VSSADMIN.EXE to
re-size the shadow storage size as seen in the sample batch file:

EXAMPLE: (where s: is the volumes used for shadow copies)

vssadmin resize shadowstorage /for=f: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=g: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=h: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=i: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=j: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=k: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=l: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=m: /on=s: /maxsize=36GB
vssadmin resize shadowstorage /for=n: /on=s: /maxsize=30GB
vssadmin resize shadowstorage /for=x: /on=s: /maxsize=10GB

Hope this helps.

Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no rights.
======================================================



--------------------
Thread-Topic: KB913648 Volume Shadow Copy Service update
thread-index: AcbXe6FeJZ7OY4OKQB2NKQ7IZ2YGOg==
X-WBNR-Posting-Host: 67.107.239.103
From: =?Utf-8?B?RGFuIERhdmlz?= <In_Finite@xxxxxxxxxxxxxx>
References: <5D99363C-DA85-4101-9AE3-6AECF5661F08@xxxxxxxxxxxxx>
<qqEoj0U1GHA.2156@xxxxxxxxxxxxxxxxxxxxx>
Subject: RE: KB913648 Volume Shadow Copy Service update
Date: Wed, 13 Sep 2006 14:29:01 -0700
Lines: 194
Message-ID: <FCEEE082-70D6-4279-84E1-EAD00234E846@xxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 8bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Newsgroups: microsoft.public.windows.file_system
Path: TK2MSFTNGXA01.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.file_system:9775
NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
X-Tomcat-NG: microsoft.public.windows.file_system

Vincent,

I'm not sure you read my full post. Please read my full post.

I did provide a poolmon report showing the npp usage.
I'm currently getting an Event ID 20 after a reboot.
I am NOT using /3G
I typically maintain 15-20 snapshots of 1.8 million files taking around
500GB of storage.

From what I understand, I'm well within sane limits of VSS, yet it still
fails to maintain snapshots between reboots. This is very unacceptable
since
both MS & Veritas boast so well about this type of setup.

-Dan


"Vincent Xu [MSFT]" wrote:

Hi,

Based on the error event log, I performed lots of research and I found
some
possible cause:



Cause 1
A driver installed on the system is using an excessive amount of
non-paged
pool. This may indicate a memory leak. See ¡°SOX040818700038 Error
returned
while creating the volume shadow copy:80¡±

Solution
Install Poolmon.exe and monitor on the system. Poolmon will list which
pool
tags are consuming non-paged pool. We can then determine the driver by
matching up the pool tag in the KB. If the KB does not contain a good
pointer we can then try the following. On the system in question run
the
following command.

findstr /mi <PoolTagListing> <Path to search>

This will search inside of all files in the search path and point out
those
that contain the suspect pool tag. We can then attempt to eliminate
each
driver in the listing. Be sure to search %systemroot%\system32 as well
as
\program files

Cause 2:
VOLSNAP.SYS driver used to take and manage volume snapshots requires
paged
pool memory to keep track of previous versions of files. The amount of
paged pool used for a snapshot with sufficiently many files touched on
it
is about 1 byte per file. Whenever a new block of 65536 files is
touched,
65536 bytes of paged pool are allocated. However, this also all depends
on
how many snapshots are currently mounted. This works out so that a
server
with 2 million files or less and 64 snapshots will always stay below
the
recommended 128 MB of paged pool threshold. A server with more files
might
be able to manipulate the snapshot storage size so that fewer than 64
snapshots are kept.

Solution:
Reduce the amount of snapshot storage used for all volumes so that your
total paged pool usage stays within limits. You can use VSSADMIN.EXE to
re-size the shadow storage size.

EXAMPLE: (where s: is the volumes used for shadow copies)

vssadmin resize shadowstorage /for=<drive letter>: /on=s: /maxsize=36GB



Cause 3:
3GB enabled in the boot.ini. In some cases, if we look at the drivers
that
are currently installed, the size of the snapshot storage, and the
amount
of data being written on the server, we may just run out of pool space.
With 3GB enabled reduces the amount of pool we have available to us
compared to a system without 3GB.

Solution:
Remove the 3GB switch from the boot.ini

Hope this helps.

Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader
so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no
rights.
======================================================



--------------------
Thread-Topic: KB913648 Volume Shadow Copy Service update
thread-index: AcbTgKv2vb6ymLO6Q/i3OMAz6uA1Sg==
X-WBNR-Posting-Host: 67.107.239.103
From: =?Utf-8?B?RGFuIERhdmlz?= <In_Finite@xxxxxxxxxxxxxx>
Subject: KB913648 Volume Shadow Copy Service update
Date: Fri, 8 Sep 2006 12:55:02 -0700
Lines: 56
Message-ID: <5D99363C-DA85-4101-9AE3-6AECF5661F08@xxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Newsgroups: microsoft.public.windows.file_system
Path: TK2MSFTNGXA01.phx.gbl
Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windows.file_system:9744
NNTP-Posting-Host: TK2MSFTNGXA01.phx.gbl 10.40.2.250
X-Tomcat-NG: microsoft.public.windows.file_system

UPDATE: The NPP problem seems to have subsided, but probably because
the
VSS
changes are minimal and the bitmap for the snapshot hasn't exceeded
the
remaining NPP. What has not changed is that after a reboot, we still
lose
any previous snapshots.

Event ID: 20
Source: VolSnap
The shadow copies of volume D: were aborted because of a failed free
space
computation.

Are there any new VolSanp updates that I can't find or is there soem
kind
of
alternate solution I'm missing?

OLD POST=============
KB article http://support.microsoft.com/kb/913648/en-us promsies
hope,
yet
fails to deliver.

I'm using Veritas Backup Exec 10d CPS to pull from 4 other servers to
an
8TB
volume (D:\CPS\BD1\); we're about 50% capacity right now. Changes
are
fairly
minimal through the day, ranging from a few hundred MB to maybe a
couple
GB.
CPS is a writer for VSS and takes hourly snapshots to a dedicated
shadow
drive/volume (E:\).

Oh, things work great for about 4 days until the inevitable VolSnap
Event
ID: 5
"The shadow copy of volume D: could not be created due to
insufficient
non-paged memory pool for a bitmap structure."

Yah, well I've been following the VSS updates as they become
available,
each
with its own set of promises unfulfilled. What's really whacky about
this
error is that it claims the NPP is exhausted. I'm using Mark's
'System
Information', which shows NPP Limit is 261,756MB of which only
135,328MB
have
been consumed (Poolmon shows the same usage). This must infer that
VSS
is
asking for more than 126,428MB to create its bitmap, or that in its
request,
doesn't leave enough NPP leftover. Within the first two days of a
reboot
NPP
is right up there near 125MB used, so why does the next 10MB kill it?



Top 15 offenders of NPP
VoSm Nonp 61,042,712 [volsnap.sys - Bitmap allocations]
CMpa Nonp 16,083,968 [nt!cm - registry post apcs]
MmCm Nonp 8,757,520 [nt!mm - Calls made to MmAllocateC
CM44 Nonp 8,042,152 Unknown Driver
SeTd Nonp 2,661,440 [nt!se - Security Token dynamic pa
LSwi Nonp 2,584,576 [<unknown> - initial work context
MmCa Nonp 2,443,616 [nt!mm - Mm control areas for mapp
Vad Nonp 1,514,544 [nt!mm - Mm virtual address descri
TCPt Nonp 1,456,480 Unknown Driver
File Nonp 1,354,232 [<unknown> - File objects]
Pool Nonp 1,134,592 [<unknown> - Pool tables, etc.]
Thre Nonp 906,672 [nt!ps - Thread objects]
NDpp Nonp 702,864 [ndis.sys - packet pool]
Even Nonp 593,216 [<unknown> - Event objects]
Devi Nonp 551,160 [<unknown> - Device objects]






.

Relevant Pages

  • Re: New proposed DRM interface design
    ... with a separate library module + additional binary interface. ... just build the DRM for a single type of card right now. ... The snapshots have been split into a common and a hardware-specific part ... > the code is in a core separate module or driver module is only going to ...
    (Linux-Kernel)
  • RE: KB913648 Volume Shadow Copy Service update
    ... When responding to posts, please "Reply to Group" via your newsreader so ... You've already posted this idea about resizing the shadow storage due to ... VOLSNAP.SYS driver used to take and manage volume snapshots requires ...
    (microsoft.public.windows.file_system)