Best practices using fsadm with OnlineJFS to extend file systems

[Scott Lindstrom_2]

I have been searching the forum archives trying to find what I should consider the best practice when specifying the new size using fsadm and OnlineJFS to extend file systems.

The man page for fsadm explains the -b option as "-b newsize - resize the file system to newsize sectors".

In the HP System and Network Admin I class, the instructor brought up the concept of doing an inline calculation, eg, -b $((32*1024)) to represent 32 mb. So I have been using that up until now.

But does that assume a 1k blocksize? (blocksize=sector size?) If so, does anything different have to be done if the blocksize is not 1k?

Also, I have been looking at some scripts that expand on how the inline calculation is done, eg, fsadm -F vxfs -b $((1024*96*16)) /whatever

I'm not sure what this is trying to say.

There are a lot of posts on the forums here that use the mb syntax, ie, "-b 32M". Is this the best way to go since the size specification in the lvextend command (when using -L) then matches the fsadm command?

TIA, Scott

[Chris Vail]

I've always used 1024 (2^10) to for kilobytes, 1048576 (2^20) for megabytes, and 1073741824 (2^30) for gigabytes. It seems that fsadm is happy with this as well: its never complained one way or t'other.


Chris

[James R. Ferguson]

Hi Scott:

I prefer the inline method so I don't have to retype/review the calculation.

If you do:

# fstyp -v /dev/vgNN/rlvolX

...and look at the value of 'f_frsize' you will generally see the 1024 value. Regardless, this is the *actual* block size as used by VxFS.

Regards!

...JRF...

[S.K. Chan]

I've used both the mb syntax and the conventional newsize*1024 method and both have worked well for me. If you want to stick to the multiplication method, just to be sure of the blocksize (ie before you run fsadm to increase the FS size), you can run ..
# fstyp -v /dev/vg01/lvol2
for example ..
and take a look at the row that has "f_frsize" which shows the block size. Yeah .. "f_frsize" not "f_bsize". I can't remember where I read this but apparently the f_frsize represent the kernel setting fs_bsize value which is the FS block size. I tend to lean towards using the mb syntax which I think should be more robust.

[Scott Lindstrom_2]

The file system I am expanding has the following in fstyp:
f_bsize: 8192
f_frsize: 8192

But I'd like to avoid having to look this up when extending. So it appears the "M" syntax solves this?

Scott

[Sridhar Bhaskarla · Accepted solution]

Hi Scott,

My standard is to do this.

#lvextend -L 550 /dev/vg00/lvol1
#bc
550*1024
#fsadm -b 563200 /mount_point

I believe it works in terms of sectors not blocks though in many documents they mentioned about blocks and it's size of 1024.

To verify it, I created a file system with a block size of 8k (f_frsize) and tried to resize the filesystem online with the default calculation of (size*1024). It worked. So, I believe the block size is irrelavent here.

-Sri

[John Poff]

Hi,

I've tried working with the -L size option in 'lvcreate' and then trying to figure out the blocks for the -b option for 'fsadm', but it just gets too hard for my feeble brain.

What I've found that works for me is to think in terms of logical extents in the logical volume, and then to multiply that out to get my blocks.

For example, if I create a logical volume with 20 LEs, and I've taken all the default sizes for the PE size of the VG and the block size of the filesystem, I've found that I can multiply the number of LEs by 4096 and get the number of blocks I need for 'fsadm -b'. So, for 20 LEs, it would be 20 x 4096 = 81920 blocks. This also corresponds to the blocks that you will see if you do a 'bdf'. I guess the real formula I'm using is LE x 1024 x PE size, which is usually 4.

A real LVM wizard can probably explain it better, but that is what works for me.

JP

[Michael Tully]

We use the same calculation method as Sridhar.

# lvextend -L 1024 /dev/byvg/lvol
bc
1024*1024
1048576
# fsadm -F vxfs b 1048576 /mymount

[Sridhar Bhaskarla]

hmmm.. I have to blame my keyboard. I said vg01 and it typed vg00. I didn't mean /dev/vg00/lvol1 which is stand.

-Sri

[Kim Leong]

Hi Scott,

The "m" suffix with the -b option in fsadm should work fine as long as you specify the same number for the lvextend -L bit. Example below:

# bdf /home
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol6 16384 1584 13926 10% /home

# fstyp -v /dev/vg00/rlvol6
vxfs
version: 3
f_bsize: 8192
f_frsize: 1024
f_blocks: 16384
...
f_size: 16384

# lvextend -L 24 /dev/vg00/lvol6
Logical volume "/dev/vg00/lvol6" has been successfully extended.
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf

# fsadm -F vxfs -b 24m /home
fsadm: /dev/vg00/rlvol6 is currently 16384 sectors - size will be increased
# bdf /home
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol6 24576 1584 21606 7% /home

# fstyp -v /dev/vg00/rlvol6
vxfs
version: 3
f_bsize: 8192
f_frsize: 1024
f_blocks: 24576
...
f_size: 24576

I guess if you are not using round numbers for your fs sizes then you need to use the sectors method and do some calculations.

Hope this helps.