Time for fsadm to Run

[Emil Henry]

Hello!

I am running the following because I need to reduce size of the filesystem from 24GB to 5GB. We have OnlineJFS installed on a HP-UX 11i machine. I am running "fsadm -d -D -e -E /fileystem" and the first output is listed below.

Directory Fragmentation Report
Dirs Total Immed Immeds Dirs to Blocks to
Searched Blocks Dirs to Add Reduce Reduce
total 17870 6378 12708 47 65 109

Now to the question. How long should this take? It has been running for the last 90 minutes. Maybe, I should have just backed it up, reduced the size and restored. Also, can I break in to it without any harm?

Regards,

Emil

[Leif Halvarsson_2]

Hi,
The time depends on how fast the disksystem and perhaps the CPU (and, of course of the size of the filesystem) but it will take quite a long time. I havr run this command only a few times and on bigger filesystem, it took the whole night. 90 minutes don't seems to be abnormal.

[T G Manikandan]

It also depends on the usage of the file system i.e. how much is it filled up?


More the usage space the more time it takes.
you could have added to option -v (verbose) to the command like to check out the output messages.

[Emil Henry]

Hello!

It took about 4 hours to complete. I have never used fsadm to defrag (as far as I remember). Does it make that much of a difference? Our disk are pretty old.

Regards,

Emil

[Leif Halvarsson_2]

Hi,

As defragmentation is a veru disk intensive operation I think the time is direct proportional to the average seek time for the disk. Defragmentation for a disk with 5ms average seek time will be 4 times faster the a disk with 20ms.

[Bill Hassell]

As mentioned, defrag is a very intensive operation, requiring massive reorganization of all the free and occupied inodes. This must be done in an 'atomic' manner which means that if any other system activity (especially writes) occur on the filesystem, they must be delayed until activity windows occur in the defrag process. This is to insure a stable filesystem. If the occupied filesystem space is about 4Gb or more and it has in the past contained much larger amounts of data, there certainly can be a lot of holes that need to be moved, a slow process. So hours would not be unusual. This is one of those cases that a tape backup or disk-to-disk backup, umount the volume, resize it using lvreduce, run newfs and then mount and restore, would be much faster.

[Jeff Schussele]

Hi Emil,

I'm somewhat confused with your question.
IF your intent is to *reduce* the FS size then the command would be:

fsadm -F vxfs -b xxxx /mnt_point

Where xxxx=new *smaller* size in sectors.

But this can be a dodgy command as there's no guarantee that there's no data in the higher sectors that would be reduced. BUT, you may have helped yourself by defragmenting the FS first.
I would DEFINITELY run 2 fbackups on this FS *before* I attempt the reduction.

HTH,
Jeff

[Tim Sanko]

The time is actually a function of disk speed and data to be handled. It would not surprise me if it took all night. It really would depend on how fragmented the front end of the volume is and how fast the heads seek, and how fast they spin...

Tim