+++ 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. bear-03[11:36am]#gfs2_tool layout gfs2_tool: unknown action: layout -- Additional comment from rpeterso 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 swhiteho 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 directly. 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] Project proposal 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 filesystem.
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.
Hi Steven, I will look at it soon.
Hi Steve, 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 up here.
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.