This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 441754 - GFS file system directories all have unclearable jdata flag set
GFS file system directories all have unclearable jdata flag set
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-utils (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Robert Peterson
GFS Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-09 16:02 EDT by Steven J. Levine
Modified: 2010-01-11 22:34 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-07 06:32:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steven J. Levine 2008-04-09 16:02:57 EDT
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:
Comment 1 Robert Peterson 2008-10-02 13:26:52 EDT
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.
Comment 2 Steve Whitehouse 2008-10-07 06:32:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.