[SUMMARY-II] VxVM Volume/UFS overhead

• Previous message: Dell, Mary: "SUMMARY: How to use SNMP to monitor for a panic?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: <sunmanagers@sunmanagers.org>
Date: Thu, 28 Oct 2004 22:13:23 +0200

Another note from Darren Dunham:

Traditionally, the default was 10%. However in recent versions of
Solaris the default was changed to be smaller on bigger volumes.

>From the Solaris 8 'newfs' man page

                 The default is ((64 Mbytes/partition size) *
                 100), rounded down to the nearest integer and
                 limited between 1% and 10%, inclusively.

So anything over 6.4 GB on Solaris 8 should already be using a minfree
of 1% (unless overridden).

Thanks.

Levi

-----Original Message-----
From: Levi Ashcol [mailto:leviashcol@hotpop.com]
Sent: Tuesday, October 26, 2004 10:31 PM
To: 'sunmanagers@sunmanagers.org'
Subject: [SUMMARY] VxVM Volume/UFS overhead

The original post is below.

Thanks to:
 Darren Dunham
 Kevin Johnson
 francisco [frisco@blackant.net]
 Doug Granzow
 Nathan Dietsch
 Miller Alan

Summary:

1- In general, most of the Volume Manager overhead comes from
the allocation of the private region, and from rounding effects due to
keeping volumes aligned on cylinder boundaries. Loss of space within a
volume tends to be an insignificant component.

2- The UFS overhead is controlled with a factor called minfree and its
default value is 10% of the filesystem size.

3- The minfree space is not wasted, but it reserved for the root user.
Any process running as root can continue to write to disk until all disk
space is used up. This is to protect the system from accidental or
intentional excessive disk space consumption from non-root users.

4- Controlling the value of minfree is done when creating a filesystem
with newfs -m or dynamically after creation of the filsystem using
tunefs -m 1 /filesystem (where 1 is the required percentage).

5-To know the current minfree value (percentage) of a filesystem:
  fstyp -v /dev/vx/rdsk/datadg/apps_bin | grep minfree.

6- Decrease the minfree to 1% has nothing to do with performance as
wrongly indicated in the tunefs man page see Sun infodoc: 15769

Thanks

Levi

-----Original Message-----
From: sunmanagers-bounces@sunmanagers.org
[mailto:sunmanagers-bounces@sunmanagers.org] On Behalf Of Levi Ashcol
Sent: Monday, October 25, 2004 5:44 PM
To: sunmanagers@sunmanagers.org
Subject: VxVM Volume/UFS overhead

Hi Gurus,
 I have a SF280 Server connected to external EMC Storage. (Solaris
8-108528-27) (Using VxVM VERSION: 3.2,REV=08 and UFS)

I noticed a massive waste of disk space when creating a new concatenated
volume and a filesystem on it.

Look at the following:
#df -k
Filesystem kbytes used avail capacity
Mounted on
   /dev/vx/dsk/datadg/apps_bin 294910784 92205081 173214625 35%
/apps/bin
   /dev/vx/dsk/datadg/apps_data 39321424 9 35389273 1%
/apps/data

The first volume is around 294GB in size, however if you add the
used/avail it will gives you
Around 265 GB. i.e: a waste in space about 30 GB !!!
For the second volume there is a waste in space around 4GB !!!.

My questions:
  - Where did this spaces gone, Is this a normal behavior ? Is it logic
for VxVM to eat 30 GB for VxVM operations ?!
  - What is the percentage of filesystem overhead from the total
filesystem size ?
  - Are there any overheads imposed from the Volume manager and what is
the percentage of this overhead ?
  - Any mount option or kernel parameter to correct this ?

Here are the c/c's of the volumes:
# vxprint -htA | grep apps_bin
v apps_bin - ENABLED ACTIVE 629145600 SELECT -
fsgen
pl apps_bin-01 apps_bin ENABLED ACTIVE 629145600 CONCAT
- RW
sd datadg03-01 apps_bin-01 datadg03 0 214141440 0
c6t5d208 ENA
sd datadg04-01 apps_bin-01 datadg04 0 214141440 214141440
c6t5d209 ENA
sd datadg05-01 apps_bin-01 datadg05 0 200862720 428282880
c6t5d210 ENA

# vxprint -htA | grep apps_data
v apps_data - ENABLED ACTIVE 83886080 SELECT -
fsgen
pl apps_data-01 apps_data ENABLED ACTIVE 83888640 CONCAT -
RW
sd datadg01-02 apps_data-01 raid_dg01 3148800 83888640 0
c6t5d212 ENA

I will Summarize definitely !

Thanks

Levi
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers

• Previous message: Dell, Mary: "SUMMARY: How to use SNMP to monitor for a panic?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]