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

From: Julian Rogan (Julian.Rogan@Unilever.com)
Date: Wed Feb 04 2004 - 14:03:41 EST


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)


This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:38 EDT