Red Hat Bugzilla – Bug 441754
GFS file system directories all have unclearable jdata flag set
Last modified: 2010-01-11 22:34:14 EST
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
[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.
Steps to Reproduce:
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
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.