I would like to have a tool called tunegfs2 which would be "argument compatible" with tune2fs where possible. This tool would deal only with settings relating to the super block. Eventually when gfs2_tool is no longer required to set the various sysfs tune parameters, that tool will be obsolete and tunegfs2 would be the new way to change super block options. -L for setting the volume label (fsname) -U for setting the UUID -l list the contents of the super block -o to set mount options (i.e. the locking type) It is debatable as to whether we'd want to support any of the journal adding options since we already have gfs2_jadd and our journal adding is different to that of ext3.
To clarify my thoughts on this one.... I'd like to see a tool which: 1. Supports both gfs and gfs2 (obviously -U option doesn't apply to gfs1) 2. Does not use libgfs2 (standalone) 3. Has the hooks in it for translation of strings (see other gfs2-tools for example) 4. Is small and simple
Goldwyn, you should be able to see everything now. Let me know if there is anything more you need.
Steve: Could you elaborate on -o option of the tool. How do you want the -o option to work? Is it to be specified as "-o lock_dlm" or "-o lock_nolock"? If yes, won't -p be a better option like it is in mkfs?
I was thinking -o lockproto=lock_dlm,locktable=sometable In other words, they should be specified as if they are mount options to the filesystem in order to match the tune2fs way of doing things. We cannot specify the defaults for other mount options at the moment, due to the way in which the lock info is stored in the sb, but doing it this way would allow us to add such things should we change the sb to allow it in the future. I'd rather stick with the tune2fs arguments rather than use the ones from our mkfs function some of which are non-standard, like -p
Created attachment 435437 [details] Add tunegfs2 main file
Created attachment 435438 [details] [2/3] Superblock operations I am not sure the way I am calculating the start of superblock. Could someone verify that?
Created attachment 435439 [details] [3/3] Makefile changes
That looks like a pretty good start to me. Do you have access to the gfs2-utils git tree? if not then we should try and arrange access for you. My only real comments are that it would be nice to eliminate the need for libgfs2 (even if that means copying the odd function into the code) since the functions in the library are, in general, not very well designed and it is tricky to make changes since they tend to be used by a number of different utilities and they often all want something slightly different from the same function. Its not that big a deal though if its going to be tricky to do. Also we need to allow for gfs1 support too. That will probably require copying in the header with gfs1 on-disk structures from the gfs1 code. Otherwise, that looks like a really good start, many thanks for looking into this and for making such fast progress. It is very much appreciated.
(In reply to comment #9) > That looks like a pretty good start to me. Do you have access to the gfs2-utils > git tree? if not then we should try and arrange access for you. Yes, I have read-only access. > My only real comments are that it would be nice to eliminate the need for > libgfs2 (even if that means copying the odd function into the code) since the > functions in the library are, in general, not very well designed and it is > tricky to make changes since they tend to be used by a number of different > utilities and they often all want something slightly different from the same > function. Its not that big a deal though if its going to be tricky to do. I am not using the libgfs2 library, but the header only. In any case, we should be able to eliminate the header as well. Let me check that. > > Also we need to allow for gfs1 support too. That will probably require copying > in the header with gfs1 on-disk structures from the gfs1 code. I din't look hard enough for these data structures.. only looked in the kernel tree. I have now found them in the gfs1-utils, and will incorporate it.
Ok, sounds good. We should be able to arrange write access to gfs2-utils for you rather than just read access. Do you have a FAS account?
(In reply to comment #11) > Ok, sounds good. We should be able to arrange write access to gfs2-utils for > you rather than just read access. Do you have a FAS account? Thanks. Just created a FAS account. username: goldwyn
Created attachment 435705 [details] [1/3] Add tunegfs2 main file
Created attachment 435706 [details] [2/3] Superblock operations
Created attachment 435707 [details] [3/3] Makefile changes
I figured out that importing structures is not required. All requirements to include libgfs2.h have been eliminated. Only linux_endian.h from the group includes is required now. The program now reads gfs1 data into the gfs2 structure. The program behaves differently only to handle UUID (which is missing in GFS1)
Patches committed to gfs2-utils.git Now it has better UUID handling. Not sure what the status of the bug should be now.
Well with Fedora bugs, I don't tend to worry too much. We could close it as "upstream" or keep it open until the tools appears in fedora and close it then. Might be useful to keep it open just for a little bit to track progress and then close it if there are no further issues in a little while. Thanks for working on this one though, its really helped push this forward.
Can we please get the install path of the tool fixed? I mailed a comment for the Makefile.am patch that is incorrect, I´d like that to see addressed.
Created attachment 437655 [details] Fix install path (In reply to comment #23) > Can we please get the install path of the tool fixed? > > I mailed a comment for the Makefile.am patch that is incorrect, I´d like that > to see addressed. I did not receive any mail. Did you send it to the mailing list? In any case, the attached patch should put the installable in /usr/sbin instead of /sbin. If that is correct, I will push the patch.
(In reply to comment #24) > Created an attachment (id=437655) [details] > Fix install path ACK'ed. > > (In reply to comment #23) > > Can we please get the install path of the tool fixed? > > > > I mailed a comment for the Makefile.am patch that is incorrect, I´d like that > > to see addressed. > > I did not receive any mail. Did you send it to the mailing list? Both to cluster-devel and your fedora email address. > In any case, the attached patch should put the installable in /usr/sbin instead > of /sbin. If that is correct, I will push the patch. Yeps, that's fine. Push at will. Fabio
(In reply to comment #25) > (In reply to comment #24) > > Created an attachment (id=437655) [details] [details] > > Fix install path > > ACK'ed. > This patch is pushed as well. Thanks for your review.
This will appear in fedora just as soon a gfs2-utils reappears as a package in its own right.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.