Description of problem: All directories in a GFS file system have the data flag set, and this flag cannot be cleared. The jdata flag is documented as being a file attribute, as opposed to the inherit_jdata flag which is documented as being a directory attribute. And yet all directories created in a gfs file system appear with the jdata flag set and attempts to clear this flag yield an error message: [root@tng3-1 gfs]# gfs_tool stat /mnt/gfs/newdir ... Flags: jdata [root@tng3-1 gfs]# gfs_tool clearflag jdata /mnt/gfs/newdir gfs_tool: can't change flag on /mnt/gfs/newdir: Invalid argument This flag seems to have no functional purpose on a directory, so it doesn't seem to be hurting anything, but why is it always and unclearably present? Version-Release number of selected component (if applicable): I'm running 5.2, but this may be true in other releases as well. How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I think I figured out what's going on here. It seems as if there are some rules that are not discussed in the gfs_tool man page, and probably ought to be. The rules go something like this: 1. A file must be zero length in order to set or clear the jdata flag. That's because if it has data, there might be data blocks associated with that file currently in the journal, and GFS is not smart enough to figure out how to untangle that. 2. A directory can't have the jdata bit set on at all, but instead has its own inherit_jdata bit. (I did not verify this in the code; this is just the behavior I observed). 3. A file within a directory that has inherit_jdata gets/inherits the jdata flag automatically when it is created. It can only be cleared if the file is zero length. 4. You can clear the inherit_jdata flag from a directory, even if there are files inside with the jdata flag set. New files created in the directory will stop inheriting the jdata flag. 5. Files created in a normal directory (i.e. without inherit_jdata flag) do not get the jdata flag when they're created, but the jdata flag may be set or cleared, but only if the length is zero. I do, however, feel that the man page for gfs_tool doesn't give any of these rules, so how is the user to know? I'd like to see this info documented both in the gfs manual and in the man page. Because this is so obscure, I have to believe that some documentation about these rules was written at some point. Maybe some docs exists from the Sistina years before Red Hat open sourced GFS. Steven, perhaps you can track that down and see if it's adequate or needs to be massaged. Just an FYI--GFS2 handles flags differently, and in a more standard Linux way, so none of this applies to GFS2. I'm going to set the NEEDINFO bit on for Kevin Anderson, requesting whether we should use this bug to make changes to the gfs_tool man page (and if so, what release), or whether I should just close the bug as NOTABUG.
This isn't a bug. The jdata flag has always been set on, since directories are journalled by way of them being metadata. In GFS the inherit jdata flag is a separate bit. It was changed for GFS2 since we use a diffeent interface to set/clear the flags and there are few bits which are usable so we have one flag which means "inherit jdata" if its a directory and "jdata" if its a file in GFS2. I know its a bit odd, but GFS is correct in this case.