Red Hat Bugzilla – Bug 239656
GFS2: gfs2_tool layout not implemented: regression from gfs1
Last modified: 2008-08-15 14:39:17 EDT
+++ This bug was initially created as a clone of Bug #221301 +++
GFS1 has the ability to print out all the blocks their
location for a particular file.
This is extremely useful information when doing performance
analysis of the file system and the underlying block device.
Print out the ondisk layout for a file:
gfs_tool layout <filename> [buffersize]
This option is not currently present in gfs2.
gfs2_tool: unknown action: layout
-- Additional comment from firstname.lastname@example.org on 2007-02-28 17:31 EST --
I can probably do this with the debugfs file system. In light of my
other debugfs changes for bz 228540, I'm reassigning to myself.
-- Additional comment from email@example.com on 2007-03-01 03:57 EST --
Abhi started looking at this the other day. Its not top of the list right now
and I don't think we need any kernel support for it. We should be able to simply
parse the fs from userspace.
This is a new bug I've created to track Andy's student project. I've cloned it
off the RHEL bug since making it an FC devel bug means I can assign it to Andy
This is a way for us to track things and I hope provide a way for us to keep in
touch with Andy over the course of the next 12 months.
Andy, you'll spot that some of the previous discussion in the bug looks a little
confusing, but you can ignore that I think. It would be a good idea to attach
the project blurb once agreed with your supervisor I think.
Created attachment 158556 [details]
I've attached the project proposal blurb that I submitted to uni. As you can
see it's pretty vague and there are a few avenues open to me. Please feel free
to steer the project in a direction that would be most useful for the
GFS2/cluster development. I'm currently trying to educate myself about things
like blktrace, libgfs2 and Linux filesystems in general and I might start
playing around with some code to experiment soon but I don't think I'll have
any working code to look at for a while yet.
To give a picture of the schedule I'll be working to, the structure of our comp
sci projects dictates that I have to do research over the summer, submit an
assessed project spec document around October and then have the code,
dissertation etc. finished for May/June 2008. After that, anything goes, so if
I end up with something useful I'll most likely carry on maintaining it
alongside my other open source projects.
I hope that introduction was helpful. I look forward to getting started.
Yes, that looks good. Let us know if you need any info on the internals of the
Also on the visualization front, vtk or matplotlib might be the things to chose,
as they should do most of the hard work for you on that front.
Just a quick update. I've now handed in my "Initial Document" for the project so
the first boring bit is out of the way and I can get on with writing some code.
Once I've got something working I'll make it available.
I'm pleased to say that my student project has finally reached a point where I
can make the code available. Bear in mind that it's not by any means 'complete'
and it should be thought of as a prototype on which to build and improve. It may
not even be very useful at the moment. So if you have any bugs to report feel
free to email me and I'll see to them when I have fewer dissertations to write :-)
That said, it should be minimally usable in its current form and I'd like to get
your feedback on any of its aspects. Note that it currently misses out a lot of
gfs2's metadata block types e.g. it doesn't read the rindex to discover the
resource groups yet but this will be implemented in due course.
I've made the git repository available here:
git clone http://andrewprice.me.uk/git/askant.git
Unfortunately I cannot run gitweb or a git daemon on that server so please let
me know if there is somewhere more suitable where it could be hosted long-term.
I've attempted to provide useful docs with askant so the README, INSTALL,
PLUGINAPI files and './setup.py --help-commands' should be good places to start.
A man page and better code comments are on my (long) to-do list.
Thank you for your patience and I hope you find my little program has some
potential to be useful for Linux file system developers :-)
Fabio, could we add Andy's project (see comment #6) into our main code base
somehow? I'm worried that it will be lost if we don't have it in the same place
as the rest of the code.
I will look at it soon.
I had a chat with Fabio on IRC and the outcome was that I'll relicense Askant as
GPLv2+, push my outstanding work to my git repository and let Fabio know when
it's ready to be imported. The commit history will probably have to be
discarded, but I think that's acceptable.
Fabio asked if it should be shipped in the standard packages (?) but I'm not
sure how to answer that as they're not my packages :) Perhaps we can clear that
Ok, sounds good. I think we can close this bug then.
My remaining changes have been pushed and it's now under GPL2+, as discussed.
As per comment #10 I'm going to close this bug now. The only reason we'd use it would be for communication and email and IRC are more suitable for that. Plus I've graduated and askant is now in the cluster git repository (andyp_askant branch initially). Thanks all.