Other Hack against 88 character mount path limitation - what is it?

There are some rumors that there is some sort of limitation to 88 characters.

A webpage about the iocell jail manager indicates such.
They offer even a hack against that problem.
They call it "hack88" and promise that ZFS will not make problems for users of the hack.

Can somebody please explain what this "88 character problem" exactly is?
What problems does it cause?
What does the hack do?
 
See statfs(2):
Code:
     #define MNAMELEN        88              /* size of on/from name bufs */
...
...
     char      f_mntfromname[MNAMELEN];  /* mounted filesystem */
     char      f_mntonname[MNAMELEN];    /* directory on which mounted */
 
Thank you very much, SirDice!

If I understand correctly, this means that the path name lengths of mounts must not exceed MNAMELEN chars, i.e.
mount /very/long/source/path /very/long/target/path
only works up to 88 char path lengths.

Does this apply to realpaths only?
Or does MNAMELEN apply to links too?

I mean, if I say
ln -s /insanely/long/path /shortcutpath

would I then be able to mount using

mount /shortcutpath /target?

Or is the solution to take care that the source paths do not get too long?
Maybe by for example using /v/l/s/p as directory names instead of /very/long/source/path?
And if long target paths are needed, just make links from /very/long/target/path to /v/l/t/p?

Sorry for asking...
I have very little idea about kernel things and just want to make sure I understand correctly.
 
You may be interested in this:
The ino64 branch extends the basic system types ino_t and dev_t from
32-bit to 64-bit, and nlink_t from 16-bit to 64-bit. The struct dirent
layout is modified due to the larger size of ino_t, and also gains a
d_off (directory offset) member. As ino64 implies an ABI change anyway
the struct statfs f_mntfromname[] and f_mntonname[] array length
MNAMELEN is increased from 88 to 1024, to allow for longer mount path
names.
 
Thank you very much Beastie,
it's good to see that this old small hard limit will not stay forever.

The background of my question is that I am trying to find out why this seems such a problem for (some? many?) ZFS jail users that the iocage jail manager apparently even offers a workaround ("hack88").
I mean, aren't 88 chars a lot if people abstain from excessively long directory names?!?
So I am still struggling to understand the problem and what this "hack88" does.
 
Back
Top