System Administration
Showing results for 
Search instead for 
Did you mean: 

Does symbolic link consume IO

Dave Chamberlin
Trusted Contributor

Does symbolic link consume IO

If I have a very busy filesystem on a disk, and I move that filesystem to another disk and leave a symbolic link that points to it on the original disk, what IO will the link consume? In other words, will I have effectively offloaded the high IO load to the other disk? What IO will the original disk have? thanks
Steven Schweda
Honored Contributor

Re: Does symbolic link consume IO

Any reference to a symbolic link would seem
to require a look-up to find the link text.
Knowing nothing about the OS or file system
involved, it's hard to be certain, but I'd
guess that someone would cache this value if
it's used frequently, so I wouldn't expect a
big penalty. And, in any case, the file name
is important only when opening a file, not
when reading from or writing to it.
Dave Chamberlin
Trusted Contributor

Re: Does symbolic link consume IO

Thanks - the file system is vxfs under HPUX 11.11
Steven E. Protter
Exalted Contributor

Re: Does symbolic link consume IO


I see no big penalty from doing things this way.

This seems like a good way to spread out i/o and relieve pressure on the underlying disk.

Steven E Protter
Owner of ISN Corporation
Trusted Contributor

Re: Does symbolic link consume IO

It will be a file open(), read(), and close() on the original disk to acquire the target of the link, and perhaps a traversal up the directory path if the link is relative, rather than absolute, for each access to the old directory. Then the traversal down the new path, of course.

Pretty minor, in other words, when compared to the traffic of a busy filesystem, but depending on the application it could add up.

If the add-up is a concern, then consider using a loopback filesystem mount in order to mount just the other disk's subdirectory at the old location.

mount -F lofs /newdisk/data2 /olddisk/data/data2

Just make sure you document it very carefully so that some hapless future sysadmin doesn't think he or she can delete /newdisk/data2 because it's a "duplicate copy" of /olddisk/data/data2.