long running fsadm -F vxfs -e -E -d -D - Any way to monitor current status ?

[Michele (Mike) Alberton]

Hi !

We're running fsadm -F vxfs -e -E -d -D on a J6750 (146GB drive).
The tool has been running for already an hour and we don't have a clue on what's the current status.

Is there any way to monitor what's going on ?

Thanks,

Mike

[Steven E. Protter]

Shalom,

You can do a ps -ef | grep fsadm and see that cpu is consumed.

This is almost certainly an i/o bound process and there is little you can do other than wait. The disk lights should be flashing if you look at the system or disk device.

You don't say how big the volume was and what the scope of the expansion was.

I have seen cases in itrc where a statement such as this did not finish. Interupting it however is dangerous and risks damaging the data in teh file system you are exapanding.

SEP

[Bill Hassell]

This is too late to help but never run defrag activities until you have run the reports (ie -E -D). Unless you have a very unusual pattern of data creation and deletion, it is extremely difficult to create a fragmented filesystem with VxFS (it's nothing like NTFS or other PeeCee stuff). Even with moderate fragmentation, you won't see much of a performance increase after a defrag -- the buffer cache will hide a lot of longer seeks. There's no way to report activity after starting the command. Next time, add the -v option.

[Michele (Mike) Alberton]

Hi,

thanks for the heads up. We were actually defragmenting a 48GB fs to gain 3GB to re-allocate for another FS.

We ran the stats but as part of the procedure itself so that we could not stop it.
Anyway it took about 1 hour to get the results and prompt back.

Thanks a lot !

Mike

Extent Fragmentation Report
Total Average Average Total
Files File Blks # Extents Free Blks
1356 2454 1 44957843
blocks used for indirects: 88
% Free blocks in extents smaller than 64 blks: 0.00
% Free blocks in extents smaller than 8 blks: 0.00
% blks allocated to extents 64 blks or larger: 99.86
Free Extents By Size
1: 7 2: 10 4: 20
8: 15 16: 9 32: 9
64: 10 128: 9 256: 5
512: 9 1024: 8 2048: 4
4096: 2 8192: 0 16384: 0
32768: 11 65536: 8 131072: 0
262144: 0 524288: 0 1048576: 2
2097152: 2 4194304: 1 8388608: 2
16777216: 1 33554432: 0 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0

Extent Fragmentation Report
Total Average Average Total
Files File Blks # Extents Free Blks
1356 2454 1 44957859
blocks used for indirects: 72
% Free blocks in extents smaller than 64 blks: 0.00
% Free blocks in extents smaller than 8 blks: 0.00
% blks allocated to extents 64 blks or larger: 99.86
Free Extents By Size
1: 11 2: 12 4: 22
8: 21 16: 20 32: 20
64: 23 128: 24 256: 18
512: 22 1024: 23 2048: 30
4096: 20 8192: 21 16384: 10
32768: 20 65536: 4 131072: 2
262144: 1 524288: 2 1048576: 2
2097152: 1 4194304: 1 8388608: 2
16777216: 1 33554432: 0 67108864: 0
134217728: 0 268435456: 0 536870912: 0
1073741824: 0 2147483648: 0

vxfs fsadm: /dev/vg00/rDB06Vol is currently 48300032 sectors - size will be reduced
vxfs fsadm: allocations found in shrink range, moving data
Warning: rounding up logical volume size to extent boundary at size "44992" MB.
Logical volume "/dev/vg00/DB06Vol" has been successfully reduced.
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
Warning: rounding up logical volume size to extent boundary at size "6016" MB.
Logical volume "/dev/vg00/OracleVol" has been successfully extended.

[Michele (Mike) Alberton]

Issue closed after 1 hour