from symbolic to fast links

[Luigi Manto]

Hi everyone! We are currently using HPUX v.11 that has has several symbolic links and I would want to change them all to use fast links. After making changes to the kernel parameter create_fastlinks, do I still need to do some more additional steps or will the previous symbolic links automatically be converted to use fast links?

Thanks in advance!

[Santosh Nair_1]

There is no difference between fast links and symbolic links. Fast links just referrs to the way that the OS/filesystem handles the symbolic links and is only relavent in HFS filesystems (?)

From docs.hp.com:

When create_fastlinks is non-zero, it causes the system to create HFS symbolic links in a manner that
reduces the number of disk-block accesses by one for each symbolic link in a pathname lookup. This
involves a slight change in the HFS disk format, which makes any disk formatted for fast symbolic links
unusable on Series 700 systems prior to HP-UX Release 9.0 and Series 800 systems prior to HP-UX
Release 10.0 (this configurable parameter was present on Series 700 Release 9.0 systems, but not on
Series 800 HP-UX 9.0 systems).

-Santosh

[Bill McNAMARA_1]

Mmm, I believe it does make a difference. The filesystem stores the files data in the inode on a vxfs (jfs) filesystem (up to 256 bytes) so that a disk io doesn't have to be scheduled.

I'd get the latest jfs patches and watch out for incompatabilities if you're considering NFS mounting it.

Also you may need a more up to date ignite patch to support it.

Downgrading your filesystem to earlier JFS releases won't be possible after doing this, but then you'd really want to have a good reason.. such as legacy apps or something like that.

Later,
Bill

[Luigi Manto]

According to HP's Performance and Tuning manual more I/Os are required to resolve the symbolic link. Unlike the fast links, which stores the name of the referenced file on the inode, rather than in a data block that the inode references (this is symbolic link). So I guess, there is a big difference in terms of performance and how it works.

[Santosh Nair_1]

Okay, I'm confused...according the docs at docs.hp.com, create_fastlinks seems to be relavent only to HFS filesystems right(?)

I would argue that most ppl use VxFS where possible and HFS only when necessary, i.e. /stand, so doesn't that make create_fastlinks irrelavent for the most part?

Just trying to get a clearer understanding...

-Santosh

[Carlos Fernandez Riera]

1- I thing that there are other areas more important to be tunned. Even if what you've read is true, a correct buffer cache size and DNLC ( Directory Name Lookup Cache) size will correct this issue.

2- tlinstall ( transition link install) creates all transition links on instalation; this is a system tool, so you would not change.
You can choose to remove all that links.

see man tlinstall.

[James R. Ferguson]

Hi Luigi:

My understanding of fast-links is as Santosh has noted, namely, that they apply only to HFS filesystems. Given, therefore, that most (?) of us use VxFS (JFS) filesystems for their performance and resiliency, I think this is a moot issue.

With regard to transition links, while HP software doesn?t (shouldn?t) rely on them, I?d be hesitant about blindly removing them until I made sure there were no executables, scripts or make files using them.

I would update, however, any of the aforementioned to directly reference the directories instead of transiting the transitional (symbolic) link. This would improve access speed.

Regards!

...JRF...

[Wodisch]

Hello Luigi,

as the others I am not so certain about the
fast-links working in a VxFS environment, but
they cannot hurt, and they would save some
space in your buffer cache...

BUT you will have to re-build ALL symbolic
links after booting with that new kernel,
like:

tlremove
find / -type l -exec recreatelink {} ";"
tlinstall

where "recreatelink" would look like:

#!/usr/bin/sh
# recreatelink: param 1 is the name of the link
target=$(ls -l $1 | cut -d'>' -f2)
rm -f $1
ln -s $target $1
# end

test it before using (and I am not responsible
for anything which will ever happen to you ;-)

HTH,
Wodisch