Re: How long can an inode structure reside in the inode_cache? - read the code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/12/06, Neil Brown <neilb@xxxxxxx> wrote:
On Monday June 12, hbryan@xxxxxxxxxx wrote:
> >Maybe you should spend a week reading the code?  It can be a lot of
> >fun, and you might even find a bug or two...
>
> I'm not sure how serious this suggestion is, but it could be taken as as
> advice not to ask questions like this on the list, and I'd like to say
> that the questions are entirely appropriate.

It was meant seriously, but lightly (if that makes sense), I answered
the question after all.

>
> It makes more sense to me to ask someone, via linux-fsdevel, who has
> already spent the week analyzing the code than to duplicate that effort.
>

I'm happy to have questions asked, and am happy to answer them.  But I
like to see evidence that the person asking them is putting some
effort in themselves.

In this case it was the third question in a fairly confined area.
Always fairly brief questions, with no evidence of background
research.
Now maybe that is due to language issues, or maybe they are just
someone who prefers to be terse or whatever and it certainly isn't
enough justification to be harsh, but I don't think I was harsh
(apologies if it seemed that way).


> Many people, including me, have difficulty extracting the big picture from
> Linux source code, and have very little fun trying.  Questions of object
> lifetimes and memory management are big-picture issues.  I can tell from
> reading lists such as linux-fsdevel that there are others who read Linux C
> code like they read a textbook.  (These are the folks who get irritated at
> excessive commenting and long variable names).  But for the rest of us,
> asking an expert shouldn't be discouraged.

Certainly, people should be free to ask questions. I tend to prefer
questions that demonstrate that the asker is doing some research
themselves.
  "I found this piece of code but don't quite understand what it
    does?"
  "Where should I look for code that implements ...."
  "When is foo() called, and why?

The lack of big-picture comments (and accompanying LKML discussions),
is IMO the biggest problem with Linux.  Not only does this cause
problems for people such as Xin and Uzair trying to understand the
code, but it causes large performance problems to go
unnoticed/undiagnosed.  Of course, I'm one of the ones that never
asks, i just read the code as many times as I need to (thanks LXR),
but that's because I get paid for this, and I can afford the time.

Hopefully I will be able to submit some performance patches sometime
soon, and I assure you they will have big-picture comments.  Maybe the
comments will even be kept up-to-date by people when they modify the
design.

NATE
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux