Hi there!
I've been trying to write a kernel module that is capable of locating a specific mounted filesystem (ext2/3) and dump all the inode entries that are in use. I have two questions:
1) Is it possible to know if an inode is free just by looking to its (struct ext3_inode) info or do I have to check the inode bitmap for the specific block group?
2) Does the following look correct?
--------8<--------
struct vfsmount *mountpoint = ... // fetch this from the proper namespace
struct ext3_sb_info *sbi = EXT3_SB(mountpoint->mnt_sb);
struct ext3_group_desc *egd;
struct ext3_inode *ino;
struct buffer_head *bh;
int i, j, k;
for (i=0; i<sbi->s_groups_count; i++) {
egd = ext3_get_group_desc(mountpoint->mnt_sb, i, NULL);
for (j=0; j<(sbi->s_inodes_per_group)/(sbi->s_inodes_per_block); j++) {
bh = sb_getblk(mountpoint->mnt_sb, le32_to_cpu(egd->bg_inode_table+j));
for (k=0; k<sbi->s_inodes_per_block; k++) {
ino = (struct ext3_inode *)(bh+(k*sizeof(struct ext3_inode)));
// dump contents of ino
// index of ino should be: (i*(sbi->s_inodes_per_group)) + (j*(sbi->s_inodes_per_block)) + k
}
}
}
--------8<--------
Cheers,
Felipe
My bad, I meant "bh->b_data" instead of "bh" (missed it while transcribing).
ino = (struct ext3_inode *)(bh->b_data+(k*sizeof(struct ext3_inode)));
Still, my questions stand.
As a matter of fact, I might as well ask another noobie question: Do I have to "free" (or decrease any counters) after sb_getblk() ?
I appreciate any help,
Felipe
On Tue, 24 Feb 2009, Felipe Franciosi wrote:
> Hi there!
>
> I've been trying to write a kernel module that is capable of locating a specific mounted filesystem (ext2/3) and dump all the inode entries that are in use. I have two questions:
>
> 1) Is it possible to know if an inode is free just by looking to its (struct ext3_inode) info or do I have to check the inode bitmap for the specific block group?
>
> 2) Does the following look correct?
>
> --------8<--------
>
> struct vfsmount *mountpoint = ... // fetch this from the proper namespace
> struct ext3_sb_info *sbi = EXT3_SB(mountpoint->mnt_sb);
> struct ext3_group_desc *egd;
> struct ext3_inode *ino;
> struct buffer_head *bh;
> int i, j, k;
>
> for (i=0; i<sbi->s_groups_count; i++) {
> egd = ext3_get_group_desc(mountpoint->mnt_sb, i, NULL);
> for (j=0; j<(sbi->s_inodes_per_group)/(sbi->s_inodes_per_block); j++) {
> bh = sb_getblk(mountpoint->mnt_sb, le32_to_cpu(egd->bg_inode_table+j));
> for (k=0; k<sbi->s_inodes_per_block; k++) {
> ino = (struct ext3_inode *)(bh+(k*sizeof(struct ext3_inode)));
> // dump contents of ino
> // index of ino should be: (i*(sbi->s_inodes_per_group)) + (j*(sbi->s_inodes_per_block)) + k
> }
> }
> }
>
> --------8<--------
>
> Cheers,
> Felipe
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Tue, Feb 24, 2009 at 05:13:52PM +0000, Felipe Franciosi wrote:
> Hi there!
>
> I've been trying to write a kernel module that is capable of locating a specific mounted filesystem (ext2/3) and dump all the inode entries that are in use. I have two questions:
Why are you doing this in a kernel module? What is this for?
- Ted
Hi Ted,
At this stage, it is just for practice. I'm building a kernel module that communicates with user space using a chardev and is able to take requests in order to read or change specific inode data. Right now, I'm just trying to dump the whole inode table.
Cheers,
Felipe
On Tue, 24 Feb 2009, Theodore Tso wrote:
> On Tue, Feb 24, 2009 at 05:13:52PM +0000, Felipe Franciosi wrote:
>> Hi there!
>>
>> I've been trying to write a kernel module that is capable of locating a specific mounted filesystem (ext2/3) and dump all the inode entries that are in use. I have two questions:
>
> Why are you doing this in a kernel module? What is this for?
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Tue, Feb 24, 2009 at 07:32:53PM +0000, Felipe Franciosi wrote:
> Hi Ted,
> At this stage, it is just for practice. I'm building a kernel module
> that communicates with user space using a chardev and is able to
> take requests in order to read or change specific inode data. Right
> now, I'm just trying to dump the whole inode table.
Yeah, but this is a really bad idea. Practice for *what*?
This isn't for some college class, is it?
- Ted
On Tue, 24 Feb 2009, Theodore Tso wrote:
> Yeah, but this is a really bad idea.
I am sure there are tools like debugfs that are capable of doing this in a much fashionable way, but that's not what I've asked and not what we should be discussing, is it?
> Practice for *what*?
I'm studying the kernel and the ext3fs in order to consider using it as a prototype for some ideas regarding my PhD. Therefore I'm practising developing modules, handling filesystem structures in different ways and the communication with user space using chardevs, debugfs and procfs. It's called PRACTICE. That's usually how people learn things and consolidate knowledge. If I was developing some secret project for NASA, do you really think I would e-mail you to ask these things!?
> This isn't for some college class, is it?
No, it is not. Where would you get that idea from?
To be very honest with you, I don't see why you are wasting your time questioning me about these things instead of simply answering what I've asked or saying something like: "Have a look at brelse() and the inode bitmap manipulation routines used in ialloc.c".
I'm beginning to believe you didn't know the answers to my questions, Ted. How sad.
My very best regards,
Felipe
p.s. if *anyone else* in the list can help me, feel free to reply directly to me and discuss the matter.
On Feb 24, 2009 21:48 +0000, Felipe Franciosi wrote:
>> This isn't for some college class, is it?
>
> No, it is not. Where would you get that idea from?
Because there are lots of questions like this from university
students that would rather have the mailing list do their
homework for them.
> To be very honest with you, I don't see why you are wasting your time
> questioning me about these things instead of simply answering what I've
> asked or saying something like: "Have a look at brelse() and the inode
> bitmap manipulation routines used in ialloc.c".
>
> I'm beginning to believe you didn't know the answers to my questions,
> Ted. How sad.
How sad that you have just been rude one of the main ext2/3/4 developers,
e2fsprogs maintainer, and one of the most senior Linux kernel developers.
I would suggest that you look at what ext2_iget->ext2_get_inode() is doing.
You will have a hard time getting much help from the list unless you change
your attitude.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
Hi Andreas,
On 25 Feb 2009, at 04:06, Andreas Dilger wrote:
> On Feb 24, 2009 21:48 +0000, Felipe Franciosi wrote:
>>> This isn't for some college class, is it?
>>
>> No, it is not. Where would you get that idea from?
>
> Because there are lots of questions like this from university
> students that would rather have the mailing list do their
> homework for them.
I'm sorry, but quite honestly, I don't think my questions looked like
"hey, can someone do this for me?".
I've had replies from other people in the list. Some with similar
questions, but believe me, AFRAID of asking them publicly exactly
because you can get this kind of reply.
And as I've said to another member of the list that also contacted me
privately: I'd rather help students with humble and honest questions
than developers that lie about their skills to get a job and then go
to mailing lists to get their work done for them.
> How sad that you have just been rude one of the main ext2/3/4
> developers,
> e2fsprogs maintainer, and one of the most senior Linux kernel
> developers.
I know exactly who he is and how good he is (at least, technically),
because I follow this list's discussions. I just don't see how he is
helping by not only refusing to answer, but also constantly and
publicly asking questions about my intentions in an offensive manner,
already criticising the way I'm experimenting something.
> I would suggest that you look at what ext2_iget->ext2_get_inode() is
> doing.
Thank you. This is the kind of reply I was expecting. Much appreciated.
> You will have a hard time getting much help from the list unless you
> change
> your attitude.
Unless some people stand up and say something about this type of reply
from time to time, NO ONE is getting any help here.
As a matter of fact, I didn't see any critics to the question below. I
can only assume that messing with inodes can look academic or not
depending on the phase of the moon or something.
------------------8<------------------
On 6 Jan 2009, at 10:36, Rohit Sharma wrote:
> I want to read data blocks from one inode
> and copy it to other inode.
>
> I mean to copy data from data blocks associated with one inode
> to the data blocks associated with other inode.
>
> Is that possible in kernel space.?
> --
------------------8<------------------
My very best,
Felipe
On Wed, Feb 25, 2009 at 10:59:22AM +0000, Felipe Franciosi wrote:
>> Because there are lots of questions like this from university
>> students that would rather have the mailing list do their
>> homework for them.
>
> I'm sorry, but quite honestly, I don't think my questions looked like
> "hey, can someone do this for me?".
Actually, it looks a huge amount like questions I've gotten in the
past, where, after I push the students a little, they admit that they
are taking undegraduate classes and that they were lazy and it really
was for a problem set for some undergraduate introduction to operating
systems class. About half the time the Really Dumb Approach was
caused by a clueless professor and it was driven by the problem set
question; the other half of the time the Really Dumb Approach is
caused by the students being completely in the weeds.
So out of respect of the pedogagical process, these days *whenever* my
"this might be a bogus problem set" warning light goes on, I always
quiz people asking for progamming assistance. If you really are a
Ph.D. student, and someday you are teaching undergraduates, hopefully
you would appreciate might care in trying to not help undergraduates
attempting to cheat on problem sets. (Whether it is students trying
to cheat on a problem set, or developers who lie about their skills
and then try to get work done by asking on the mailing lists --- I
prefer not to help either, thank you very much.)
As far as your approach is concerned, you asked a whole bunch of
questions which were just *off*. They made no rational sense, and
even if you are practicing, sometimes the wrong kind of practicing can
end up doing far more harm than good. If you have code that
completely bypasses all of the normal abstraction layers, the danger
is that you might actually try to use it later, or get confused into
thinking that this was a valid thing to do. It's like practicing to
compose counterpoint where there is a huge numbers of parallel fifths
between the bass and soprano lines. What you did would be the
equivalent of asking a composer with help with the interior voices,
and the composer notices and raises questions about the parallel
fifths in the outer voices, and observes that helping you would be
doing you a disservice, because you are *practicing* *the* *wrong*
*thing*.
In this particular case, you mentioned that you want to be able to
access and change the inodes. Well, there is an inode cache, and
bypassing the inode cache while the filesystem is mounted will only
give you possibly out of date information if you are reading, but will
be ***disastrous*** if you plan to (in your worlds) "change specific
inode data". So this is not a question of doing things in a more
"fashionable" way. It is a question of doing things the right way or
the data corrupting way.
Finally, please note that I, nor any other kernel developer that you
might try to cozen, am under no obligation to dispense free progamming
advice. Your attitude seems to be that we all exist to help you out,
and that we are obliged to spend time answering your questions. If
someone will eventually be contributing to the kernel, and submitting
useful ext4 patches, I'll give that person some beginning pointers.
But most of the time such contributors start by trying to implement
something useful, not just "practice". If you are just practicing,
and your only interests is to develop your own skills, and get your
own Ph.D., why the heck should I help you? Personally, I think the
world needs a lot more Ph.D.'s that don't have attitude, so if someone
is going to be an *sshole, the last thing that I would find an
appealing is using some of my precious free time (that would otherwise
be devoted towards making ext4 better) and waste it instead helping
them get that Ph.D., at which point they will probably be even more
offensive to others because they think the "Dr." title makes them
better than everybody else.
The bottom line is that this is a list about ext3/ext4 development.
If someone wants to ask a question, and it doesn't make sense why they
are asking a question, I'm going to ask them why. In some cases this
is important, because otherwise I might give them a wrong or
misleading answer. But it's also because if we let every single
person who has a random "I want to learn how to program the kernel"
swamp the list, we'd have no time to work on what the folks on the
community *really* is interested in doing, which is making ext3/ext4
better and more stable filesystems.
- Ted
On Wed, Feb 25, 2009 at 5:59 AM, Felipe Franciosi <[email protected]> wrote:
>
> As a matter of fact, I didn't see any critics to the question below. I can
> only assume that messing with inodes can look academic or not depending on
> the phase of the moon or something.
>
> ------------------8<------------------
> On 6 Jan 2009, at 10:36, Rohit Sharma wrote:
>>
>> I want to read data blocks from one inode
>> and copy it to other inode.
>>
>> I mean to copy data from data blocks associated with one inode
>> to the data blocks associated with other inode.
>>
>> Is that possible in kernel space.?
>> --
By chance that question was also asked on the kernelnewbies list.
The first responses there were also of the form "Why do you want to do that?"
FYI: It started a very long thread discussing what they were actually
doing. (This was part of the OHSM project that has been mentioned here
a couple times.) It was eventually determined the proposed
online_defrag patchset was very similar to their need.
Greg
--
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf
The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
On Wed, Feb 25, 2009 at 10:59:22AM +0000, Felipe Franciosi wrote:
> As a matter of fact, I didn't see any critics to the question below. I
> can only assume that messing with inodes can look academic or not
> depending on the phase of the moon or something.
>
> On 6 Jan 2009, at 10:36, Rohit Sharma wrote:
>> I want to read data blocks from one inode
>> and copy it to other inode.
>>
>> I mean to copy data from data blocks associated with one inode
>> to the data blocks associated with other inode.
>>
>> Is that possible in kernel space.?
>> --
Actually, I asked Rohit what they were doing back September, 2008.
http://article.gmane.org/gmane.comp.file-systems.ext4/9142
Personally, I'm not really convinced by the approach which the fscops
project is adopting, but that's up to them to figure out. I was
amused though by their powerpoint slides which claim that they are "on
the way to being accepted in the mainline kernel" --- that seems a
little gradious, given that they haven't even submitted any code for
review yet.
- Ted
Theodore Tso wrote:
>
> On Wed, Feb 25, 2009 at 10:59:22AM +0000, Felipe Franciosi wrote:
>> As a matter of fact, I didn't see any critics to the question below. I
>> can only assume that messing with inodes can look academic or not
>> depending on the phase of the moon or something.
>>
>> On 6 Jan 2009, at 10:36, Rohit Sharma wrote:
>>> I want to read data blocks from one inode
>>> and copy it to other inode.
>>>
>>> I mean to copy data from data blocks associated with one inode
>>> to the data blocks associated with other inode.
>>>
>>> Is that possible in kernel space.?
>>> --
>
>
>
> Actually, I asked Rohit what they were doing back September, 2008.
>
> http://article.gmane.org/gmane.comp.file-systems.ext4/9142
>
> Personally, I'm not really convinced by the approach which the fscops
> project is adopting, but that's up to them to figure out. I was
> amused though by their powerpoint slides which claim that they are "on
> the way to being accepted in the mainline kernel" --- that seems a
> little gradious, given that they haven't even submitted any code for
> review yet.
>
>
Hi Ted,
I know we became a bit futuristic at that point in time when we saw a mail
from Akira mentioning that you guys are planning to provide a ABI to provide
block allocation in restricted block group range(s), option(2) in the
following mail.
http://patchwork.ozlabs.org/patch/12877/
which would have made the OHSM work more simpler and compatible with
the current linux framework.
Also, there was a piece of code submitted from our end too, as a support to
the above option(2)
http://kerneltrap.org/mailarchive/linux-ext4/2009/1/26/4813934
asking if it would be feasible, if we go ahead and implement the same
for ext4.
Later, when we realised the complexities involved and saw some replies from
your end regarding the concept of OHSM. We have started being more cautious.
I believe we have also sent a recent reply to one of your mails on the
feedback to the idea of OHSM. It would be great if you can just pull out
some small amount of time to have a look at it atleast.
http://www.nabble.com/-RFC--PATCH-0-3--ext4%3A-online-defrag-(ver-1.0)-tc21742025.html
Thanks & Regards,
Rishi.
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
View this message in context: http://www.nabble.com/Simple-inode-question-%28ext2-3%29-tp22186566p22754510.html
Sent from the linux-ext4 mailing list archive at Nabble.com.