[HPADM] RE: 10.20 - FIlesystems increased beyond 128 GB ** UPDATE **

From: Julian Rogan (Julian.Rogan_at_Unilever.com)
Date: 02/04/04

  • Next message: Colin Foo: "[HPADM] Final FLORUG Performance Training Workshop Schedule Released" 
    Date: Wed, 4 Feb 2004 19:03:41 +0000 (GMT Standard Time)
To: "hpux-admin@dutchworks.nl" <hpux-admin@dutchworks.nl>

    I have had a few very interesting replies which I will summarize later.
    I have had an interesting developement

    After I copied the Oracle data from the read-only (corrupted) filesystem I
    found I had approx 16 GB MORE data in the new
    filesystem:

    /dev/vg01/oradbs 163840000 63084053 94458701 40% /oradbs
    /dev/vg01/oradbsnew 89620480 79731763 9270712 90% /oradbsnew

    However if I use "du" to compare the disk usage of the subdirectories I
    get the following:

    du -sk /oradbs*/mnt/EKA
    18221746 /oradbs/mnt/EKA
    18161282 /oradbsnew/mnt/EKA

    du -sk /oradbs*/mnt/EKATST
    13915403 /oradbs/mnt/EKATST
    13915395 /oradbsnew/mnt/EKATST

    du -sk /oradbs*/mnt/RLINK
    47383706 /oradbs/mnt/RLINK
    47365634 /oradbsnew/mnt/RLINK

    du -sk /oradbs*/mnt/RLINKDEV
    266321 /oradbs/mnt/RLINKDEV
    266321 /oradbsnew/mnt/RLINKDEV

    i.e. du is showing LESS in the new filesystem than the original. However
    as you can see it is not 16 GB less.

    I unmounted and remounted the new filesystem but there was no change

    I now don't know whether I can trust the copy.
    Any advice out there?

    thanks

    Julian

    -----Original Message-----
    From: Julian Rogan [SMTP:Julian.Rogan@Unilever.com]
    Sent: 04 February 2004 17:11
    To: hpux-admin@dutchworks.nl
    Subject: [HPADM] 10.20 - FIlesystems increased beyond 128 GB

    Hi,

    I have just done the following (after forgetting about the 128 GB limit on
    filesystems)

    I increased a logical volume to 160 GB and then issued the fsadm command
    to increase the filesystem

    I got the message:

    fsadm: /etc/default/fs is used for determining the file system type
    fsadm: /dev/vg01/roradbs is currently 81920000 sectors - size will be
    increased
    fsadm: attempt to resize /dev/vg01/roradbs failed with errno 28

    The filesystem starting spewing out I/O errors and we lost access to the
    applications. I tried to fsck and got the
    following output:

    fsck -y -o full /dev/vg01/oradbs
    fsck: /etc/default/fs is used for determining the file system type
    intent log marked bad in super-block
    cannot perform log replay
    pass0 - checking structural files
    pass1 - checking inode sanity and blocks
    pass2 - checking directory linkage
    pass3 - checking reference counts
    pass4 - checking resource maps
    free block count incorrect 100755947 expected 84011499 fix? (ynq)y
    free extent vector incorrect fix? (ynq)y
    OK to clear log? (ynq)y
    set state to CLEAN? (ynq)y

    Mount still fails with filesystem corrupt.
    I have managed to mount th efilsystem in readonly mode and currently
    copying the data over to a new filesystem.

    So finally to my question: I there a way to fix the filesystem?

    regards,
    Julian 

    --
             ---> Please post QUESTIONS and SUMMARIES only!! <---
        To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
       Name: hpux-admin@dutchworks.nl     Owner: owner-hpux-admin@dutchworks.nl
 
 Archives:  ftp.dutchworks.nl:/pub/digests/hpux-admin       (FTP, browse only)
            http://www.dutchworks.nl/htbin/hpsysadmin   (Web, browse & search)
  • Next message: Colin Foo: "[HPADM] Final FLORUG Performance Training Workshop Schedule Released"

    Relevant Pages