what goes first to reduce a filesystem and volume jfs 3.1

[Roland Rebstock_1]

I ran into a issue last night, I was instructed to lvreduce a 260GB logical volume and then fsadm -b the filesystem..It blew up and had to restore from tape. Meta-Data got corrupted. Ive posted twice and im not seeing any warm and fuzzy on doing this with jfs 3.1. Should the fsadm been done first to shrink the filesystem or was the lvreduce the right thing to do. I hearing that this is nearly impossable to do with jfs 3.1

[Robert-Jan Goossens]

Hi Roland,

http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000067342554

Document description: How to reduce a JFS 3.1 filesystem
Document id: KBRC00011321

Regards,
Robert-Jan

[Pete Randall]

Logically, you need to shrink the file system before shrinking the container that it resides in (i.e. the logical volume). Shrinking the container first is bound to cause damage to the file system within.


Pete

[Mark Grant]

Roland,

Reduce the filesystem first!

A logical volume can be thought of as a logical disk. You have attempted to make the "disk" smaller without re-arranging the data sitting on it!

[Bernhard Mueller]

Roland,

*first* decrease filesystem size, *then* lvol with lvreduce, else you will get into trouble (you learnt that already the hard way).

According to practiacl experience with JFS 3.1 reducing filesystem size only works if the filesystem has *not* been initially created with the "large" size but gradually extended to this size. Even then hundreds of defrags using fsadm might not do the trick and fsadm -b will fail...

Regards,
Bernhard

[Alzhy]

Just as we need to expand the underlying LVOL first before the overlying Filesystem when expanding -- we need to do the same when shrinking Filesystems -- do the underlying LVOL first...

I wish though that someday the concept of volumes and Filesystems will go away and everything will be done at the storage subsystem level .. ie. the SAN... I read once that StorageWorks arrays were being planned to have that capability where in the OS need not do anything when the array LUNs are expanded or reduced - along with the filesystem.. .. that was true with VMS and Tru64 .. I hope HP will continue that plan when it "blends" Tru64's features to HPUX.. But then, what is HP's storage strategy these days? With the recent movements in its storage division and seeming confusion for the cusotmeres whether to go for the old Compaq Storage line (ie. EVA) or go with the rebadged Hitachi storage lines -- ie. the highly successful XP line..