SUMMARY N2: RE: Veritas Volume Manager and Solaris 8 disk space problem

From: Pere Blay <pere.blay_at_uv.es>
Date: Thu Aug 24 2006 - 05:39:19 EDT
Hi again,

All the previous posts are included below.

Special thanks to Darren Dunham for the quick and clear answers.
Sorry if i missed thanks to someone in this and  preivous posts.

CONCLUSIONS:

1) you can not have more than 1Tb filesystem while you stuck on UFS

2) VxFS can support more than 1Tb filesystems for disk layaout versions 5 and
higher. To determine your VxFS version:

$ pkginfo -l  VRTSvxfs

examlpe of output:

   PKGINST:  VRTSvxfs
      NAME:  VERITAS File System
  CATEGORY:  system,utilities
      ARCH:  sparc
   VERSION:  3.4,REV=GA03
   BASEDIR:  /
    VENDOR:  VERITAS Software
      DESC:  Commercial File System
    PSTAMP:  VERITAS-3.4FS-2003-01-29PID=110435-08
  INSTDATE:  Mar 17 2004 13:54
   HOTLINE:  (800) 342-0652
     EMAIL:  support@veritas.com
    STATUS:  completely installed
     FILES:      192 installed pathnames
                  24 shared pathnames
                   5 linked files
                  38 directories
                  54 executables
                   5 setuid/setgid executables
               16556 blocks used (approx)

after a looooooooooong search through documuoentation (and thanks to
indications from  Darren Dunham), i could find out that my version of VxFS
(3.4) supports disk layaouts versions 1,2, and 4, using version 4 as default.
Disk layout version 4 won't support filesistem sizes bigger than 1Tb. Later
versions (5 and 6) will do, but newer versions of VxFS are needed. Here you
are an excerpt from a document sent to me by Darren Dunham (original link:
http://support.veritas.com/docs/248416):

VERITAS File System disk layout version 6 supports the creation of file
systems up to 256 terabytes.

VERITAS File System disk layout version 5 supports the creation of file
systems up to 32 terabytes.

VERITAS File System disk layout version 4 supports the creation of file
systems up to one terabyte.


3) Then, if you have a device like the 3510, with several disks wich can give
you more than 1Tb all together, you need to split them in logical disks of
smaller sizes and mount them as different filesystems unless you have (or you
can migrate to) a VxFS version with the newer disk layout versions or
improved filesystems like ZFS (instead of UFS).

This is important to take into account prior the adquisition of such storage
devices.

My 3510 gives me now two smaller filesystems (800 Gb and 500 Gb) which i mount
in different folders, not the ideal situation as i have to deal with soft
links up and down, but sitll  trying to improve the situation (i'm studynig
the posibility to migrate to Solaris 10).


Many thaks to you all,
Pere blay


***************************************************************************
Hi,

This is the first approach to the problem... (original post at the end).

Thanks for the very quick answers of Keven Sparling, Bobby Smith,
Johan Hartzenberg,  Darren Dunham,  Jane Lecher,  Andrey Borzenkov
(and sorry if i did not spell the names properly :P)

Following their suggestions, here you are a few more info about the
partitioning (which i hope will also be usefull as a fisrt 'handout' of these
kind of commands for newbies like me):

This is the partition table ('format' output):
-------------------------
Current partition table (default):
Total disk cylinders available: 28142 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders       Size            Blocks
  0       root    wm       0 -   0        1.99GB    (1/0/0)      4173440
  1       swap    wu       1 -   1        1.99GB    (1/0/0)      4173440
  2     backup    wu       0 - 354      708.02GB    (355/49/64998) 1484831488
  3 unassigned    wm       0              0         (0/0/0)            0
  4 unassigned    wm       0              0         (0/0/0)            0
  5 unassigned    wm       0              0         (0/0/0)            0
  6        usr    wm       2 - 354      704.04GB    (353/49/64998) 1476484608
  7 unassigned    wm       0              0         (0/0/0)            0
------------------

And this is the output of prvtoc:
-------------------
> prtvtoc /dev/rdsk/c4t44d0s2
* /dev/rdsk/c4t44d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*   65210 sectors/track
*      64 tracks/cylinder
* 4173440 sectors/cylinder
*   28144 cylinders
*   28142 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
*       First     Sector    Last
*       Sector     Count    Sector
*     4173440   4173440   8346879
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
       2      5    01          0 1484831488 1484831487
       3     15    01          0   4173440   4173439
       4     14    01    8346880 1476484608 1484831487
----------------

 The number of blocks in c4t44d0s2
(1476484608) is consistent with the 704 Gb size.
It's clear that Solaris 8 is seeing 704 Gb and it's not a VXvm issue.

I googled before posting, but i must apologize becouse after googling a while
again i could find out that the filesystem size limit in Solaris 8 seems to
be 1TB, as some of you pointed to me (someone pointed out that it's 800 Gb).


Just for completion, this is the output of 'vxprnit -ht':
 --------------
dg ArchiveT3    default      default  108000   1031730160.1848.milkyway

dm Archive1     c7t1d0s2     sliced   16383    565706752 -
dm Archive2     c6t1d0s2     sliced   16383    565706752 -
dm Archive3     c4t44d0s2    sliced   524288   1476484608 -

v  archive      -            ENABLED  ACTIVE   1131413504 SELECT  archive-01
fsg
en
pl archive-01   archive      ENABLED  ACTIVE   1131413504 STRIPE  2/256    RW
sd Archive1-01  archive-01   Archive1 0        565706752 0/0      c7t1d0
ENA
sd Archive2-01  archive-01   Archive2 0        565706752 1/0      c6t1d0
ENA

v  archive2     -            ENABLED  ACTIVE   1472200704 SELECT  -
fsgen
pl archive2-01  archive2     ENABLED  ACTIVE   1473224320 CONCAT  -        RW
sd Archive3-01  archive2-01  Archive3 0        1473224320 0       c4t44d0
ENA
-------------

The new file system is 'archive2', lying in  the logical disk Archive3
(c4t44d0s2) created from 6 disk drives within the SE 3510.

POSSIBLE SOLUTION:
It seems that the smarter action to take is to split the disk space in the
SE 3510 in two or more LUNS of smaller size and  later on create a big volume
by adding these all LUNS together under VXvm.

I'll report on the solution once i finish the setup and show if it worked :)
(then, a SUMMARY N2 will follow ;) )

Thanks you all!!
Cheers,
Pere

ORIGINAL POST
---------------------

Hi,

This is my system (output from 'uname'):

SunOS milkyway 5.8 Generic_117350-38 sun4u sparc SUNW,Sun-Fire-880

I have Veritas Volume Manager 3.2 to manage my filesystems. We have added a
Sun StorEdge 3510 very recently with 6x300Gb disks in a RAID_5 configuration.
>From them, then, only 5 become available as available storage space and an
effective space of around 250Gb per disk is achieved. In total, thus, i
should have close to 1.2Tb of storage space available.

I was told that Solaris 8 has a limit on 1.5 Tb for the size of a file system.
Then i was thinking that i'm still in the safe side.

When i import, encapsulate, and so on,  the new SE 3510 disk into Veritas
Volume Manager, it reports that the available storage space is only 704Gb.
Where did the other 500Gb go? (private region created by Veritas takes only
256 Mb of space). Is there some incompatibility with the combination
V880+Veritas 3.2+SE 3510 with a file sistem as big as 1.2 Tb? Any hints/test
which can help?

Thanks a lot,
Pere


--
----------------------------------------
Pere BLay
GACE - ICMUV - Universitat de Valencia
PO BOX 22085, E-46071 Valencia
Tlf.: (+34) 96 35 4 36 08
Fax.: (+34) 96 35 4 32 61
http://castor.uv.es  ~  http://tucana.uv.es
------------------------------------------
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Thu Aug 24 13:34:42 2006

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:00 EST