Bug 664848

With a bit of work in libgfs2, it should be possible to print out, for each cdpn converted, the full path of the cdpn as well as the full path of the target.

Note that I missed this initially since it didn't have the string "gfs" in the bug title.

This bug is for the documentation part of the issue, I've opened bug #674280 to address the items in the gfs2-utils package itself.

Abhi, can you add some detail here for the docs team to follow up on?

As of now, gfs2_convert does not print these cdpn targets as it renames them to empty directories. The real issue is to make gfs2_convert give more info about the cdpns being converted so that the admin can recreate the effect using bind mounts. Bug 674280 is tracking the gfs2-utils bug that will actually implement the functionality, using which gfs2_convert can report more information about the cdpns it converts.
At this point I'm not sure if a perfect solution is possible... SteveW raised some important points; i.e the mapping isn't a 1:1 mapping (many paths to one inode) so it won't be unique, and it will fail if the cdpn target is outside the filesystem.

Bob said that he had some ideas regarding a reverse-mapping of a inode block to a full directory path that could allow gfs2_convert to print the requested information. Progress on this will be tracked in 674280. I'm don't think there's any more documentation work to be done until that is fixed.

Steve: I think that's a question for Abhi, as per the last sentence of Comment 4.

https://bugzilla.redhat.com/show_bug.cgi?id=674280#c1

SteveW mentions in this comment that it was agreed that we should document how to use the find command to spot the cdpn symlinks/targets before attempting gfs2_convert so they can be reinstated in the form of bind mounts on the gfs2 fs after conversion.

Currently the gfs2_convert appendix notes this:

------
GFS2 file systems do not provide support for context-dependent path names 
(CDPNs), which allow you to create symbolic links that point to variable 
destination files or directories. The gfs2_convert command identifies CDPNs and 
replaces them with empty directories with the same name. To achieve the same 
functionality as CDPNs in GFS2 file systems, you can use the bind option of the 
mount command. For more information on bind mounts and context-dependent 
pathnames in GFS2, see Section 3.12, “Bind Mounts and Context-Dependent Path 
Names”. 
----

I could split that up:

---------
GFS2 file systems do not provide support for context-dependent path names 
(CDPNs), which allow you to create symbolic links that point to variable 
destination files or directories. To achieve the same functionality as CDPNs in GFS2 file systems, you can use the bind option of the mount command.

The gfs2_convert command identifies CDPNs and replaces them with empty directories with the same name. In order to configure bind mounts to
replace the CDPNs, however, you need to know the full paths of the link targets
of the CDPNs you are replacing. Before converting your file system, you can
use the find command to identify the links as follows:

EXAMPLE

For more information on bind mounts and context-dependent pathnames in GFS2, 
see Section 3.12, “Bind Mounts and Context-Dependent Path Names”. 
---------------------------

Does that work?  How would you know what to specify in the find command?

I'm just noting that this is a 5.6 bug (which I'll move to 5.7 since 5.6 is out the barn door), but this info would apply to 6.1 as well, right?  I can sneak this in if we can get this set this week.

[root@smoke-01 gfs]# find /mnt/gfs -lname @hostname
/mnt/gfs/log

will give you all the symlinks pointing to the HOSTNAME cdpn. Similarly, the user can execute the find command for other cdpns (mach, os, sys, uid, gid, jid). Also note that cdpn names can be of the form @hostname or {hostname}, so this will have to be run for each variant.

Abhi: Could you look this over and review it?

http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Global_File_System_2/gfs_upgrade.html

(In reply to comment #11)
> Abhi: Could you look this over and review it?
> 
> http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Global_File_System_2/gfs_upgrade.html

I've had a look at the CDPN section and it looks good to me.

Steven, is this done now or do you need something more from us?

Steve:

I believe this is done -- I updated the RHEL 6.1 document with the information that Abhi reviewed. The reason this bug is still open is that I am just this week finishing my 6.1 work and haven't begun my 5.7 work. 

When I branch the 5.7 files I will update them and put this bug in modified.

-Steven

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

I have added the CDPN info from the 6.1 manual to the 5.7 manual draft. When I check in and build this I'll send it for review to make sure that the information applies equally to 5.7, but this note is to update the status (that this is now in my working draft).