Loading ...
Sorry, an error occurred while loading the content.

Expand Messages
  • jitin
    hi I will be using vmware sol 10 u6 oracle 10, logs are imp for 90 days, what should be recommended var size j grover
    Message 1 of 4 , Jun 3, 2009
    View Source
    • 0 Attachment
      hi

      I will be using vmware sol 10 u6 oracle 10,
      logs are imp for 90 days,
      what should be recommended var size

      j grover
    • Mike Riley
      ... Unless you are giving it really limited size that might fill up I don t even bother with a separate /var anymore. I just have /, swap, and maybe a /export
      Message 2 of 4 , Jun 3, 2009
      View Source
      • 0 Attachment
        jitin wrote:
        > hi
        >
        > I will be using vmware sol 10 u6 oracle 10,
        > logs are imp for 90 days,
        > what should be recommended var size

        Unless you are giving it really limited size that might fill up I don't even
        bother with a separate /var anymore. I just have /, swap, and maybe a
        /export on a system with exported volumes. On my larger system the RAID 5
        ZFS volume is my /export and it is it's own "slice".

        The issue I have always had with /var, especially since I started keeping
        current on patches, is that the items being patched are kept in /var so the
        patches can be backed out. Over time this can get extremely large if you
        patch often. On one system it was approaching a gigabyte.

        I filed an RFE a long time ago that you should be able to "expire" old
        patches and have them removed. Ideally you should be able to do that every
        time you do an update with a new release. That would keep the storage
        requirements lower.

        You also need to allow for crash dumps, maybe core dumps are set there, plus
        your messages and other log files. So trying to guesstimate that is likely
        to backfire. Either you allocate way too much or not enough. If you at
        least make it a ZFS volume you could always add some more storage to it from
        a pool.

        Mike
      • laurent@elanor.org
        ... Even more when systems stay used for years, it can be gigabytes, with a biannual, R/S only patching on a full install. I ve had to move /var several times
        Message 3 of 4 , Jun 4, 2009
        View Source
        • 0 Attachment
          Quoting Mike Riley <skiprof@...>:
          > The issue I have always had with /var, especially since I started keeping
          > current on patches, is that the items being patched are kept in /var so the
          > patches can be backed out. Over time this can get extremely large if you
          > patch often. On one system it was approaching a gigabyte.

          Even more when systems stay used for years, it can be gigabytes, with
          a biannual, R/S only patching on a full install. I've had to move /var
          several times on older S9 boxes.

          > I filed an RFE a long time ago that you should be able to "expire" old
          > patches and have them removed. Ideally you should be able to do that every
          > time you do an update with a new release. That would keep the storage
          > requirements lower.

          Actually, it *should* mostly work that way, but I found a bug about it
          during the last public beta of S10 (which was one or two updates ago).
          When doing LU, a lot of packages are not pkrm'd properly, and obsolete
          and totally useless stuff is left in /var/sadm, a lot of it.
          I don't know if this has been fixed, or even would be (it's not really
          a blocker....).

          > You also need to allow for crash dumps, maybe core dumps are set there, plus
          > your messages and other log files. So trying to guesstimate that is likely
          > to backfire. Either you allocate way too much or not enough. If you at
          > least make it a ZFS volume you could always add some more storage to it from
          > a pool.

          That would mean locating /var on a different zpool, right? I'm almost
          sure rpools can't be RAID1+0. I would keep /var on the rpool, but
          mount /var/log and other stuff from another one.

          Laurent
        • John Taylor
          ... It s not clear to me if you are going to running Solaris 10 U6 inside of vmware. Here is a zfs listing from my x4600 NAME
          Message 4 of 4 , Jun 5, 2009
          View Source
          • 0 Attachment
            On Wed, Jun 3, 2009 at 10:49 AM, jitin<jitingrover@...> wrote:
            >
            >
            > hi
            >
            > I will be using vmware sol 10 u6 oracle 10,
            > logs are imp for 90 days,
            > what should be recommended var size

            It's not clear to me if you are going to running Solaris 10 U6 inside of vmware.

            Here is a zfs listing from my x4600

            NAME USED AVAIL REFER MOUNTPOINT
            rpool 15.3G 119G 38.5K /rpool
            rpool/ROOT 9.01G 119G 18K legacy
            rpool/ROOT/S10U6_X86 7.21G 119G 5.82G /
            rpool/ROOT/S10U6_X86@S10U7_X86 65.7M - 3.59G -
            rpool/ROOT/S10U6_X86/var 1.33G 119G 1.30G /var
            rpool/ROOT/S10U6_X86/var@S10U7_X86 24.4M - 1.16G -
            rpool/ROOT/S10U7_X86 1.79G 119G 3.60G /
            rpool/ROOT/S10U7_X86/var 52.9M 119G 730M /var
            rpool/dump 1.00G 119G 1.00G -
            rpool/swap 2G 121G 16K -
            rpool/var_home 866M 119G 866M /var/home


            Using zfs root and defining a separate /var partition at install time (I was
            unable to make a working system by moving /var to a separate zfs
            file system after install) is you best solution. You can always expand
            the /var file system as the system evolves.

            So if you're going to be making a virtual disk in VMware, then you should
            make it large enough so you can appropriate resize if necessary. Using
            a separate zpool is probably not a good idea, unless you are going to
            separate the oracle logs to a separate device, separate from /var.

            Ben
          Your message has been successfully submitted and would be delivered to recipients shortly.