Help with Project on brtfs wiki

Help with Project on brtfs wiki

[Nick Krause]

Hey brtfs devolopers.
I am new so I think this project,Implement new FALLOC_FL_* modes needs
more information for me to
write if for you guys. I am wondering what is fallocate and how you
want me to write this, define statements
or as functions in a certain file? I am not asking to hold my hand
just point me to some documentation somewhere
and I will read it when I have time as I am working on directory speed
work for ext4.
Cheers Nick

Re: Help with Project on brtfs wiki

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 6118 bytes --]

On Fri, Jul 25, 2014 at 07:16:19PM -0400, Nick Krause wrote:
> I am new so I think this project,Implement new FALLOC_FL_* modes needs
> more information for me to
> write if for you guys.

   So you've ignored most of the advice I sent you in my last mail.
Have you even made a btrfs filesystem yet and seen what it can do?
(I'm willing to bet the answer's "no", because you haven't asked _any_
of the common questions about the filesystem yet). You're leaping into
the kernel work without understanding what it is you're working on.
How will you be able to test your work properly if you don't
understand what the user experience is like? How can you test, for
example, the behaviour of your patch in the presence of snapshots, if
you don't know how snapshots should behave? This will take time and
effort to learn. You cannot simply jump straight in to writing code if
you don't understand the basic behaviours of the thing you're
changing.

> I am wondering what is fallocate and how you
> want me to write this, define statements
> or as functions in a certain file?

   This is the wrong question to be asking. If you can't find the file
that fallocate is implemented in in btrfs, then you're simply not
putting in the necessary effort (hint: grep). Similarly, how it should
behave is also trivially discoverable (hint: man, also read the "SEE
ALSO" section). I've already directed you at the basic documentation
for btrfs internals.

> I am not asking to hold my hand

   You are, though. Something like using grep to find code that (might
be) related to the thing you're trying to work with is _fundamental_.
You should expect to be reading the code -- several layers deep, in
both directions from any given function -- in order to understand what
it does and how it fits in, and what problems you might enncounter if
you change it. If you won't put in that degree of basic effort, then
you won't get very far.

   Further, "how should I change it?" is _your_ decision as the
developer of the patch. This is most of the difficulty with writing
code. The mechanics of the code itself is usually easy. Working out
the underlying algorithms and processes is the hard part, and is where
quite a lot of the effort goes in. Asking someone else "can you tell
me what code to write, and I'll write it for you" is pretty pointless,
because if they give you the process in enough detail that you can
"just write the code", they might as well have written the code in the
first place.

> just point me to some documentation somewhere
> and I will read it when I have time as I am working on directory speed
> work for ext4.

   This implies that you've also ignored the advice given to you on
linux-kernel, to pick one subsystem and learn that in detail. You
can't sensibly, as a newcomer to the kernel, learn *both* ext4 and
btrfs in parallel.

   So, again:

 * Set up several btrfs filesystems with different configurations. Use
   VMs for this (because you'll need a VM to test your changes anyway).

 * Read the user documentation on the wiki.

 * Play with your filesystems, work out how the FS behaves -- *in
   detail*. Read the FS features on the wiki and try at least some of
   them out. Use this to understand how it should behave. In
   particular, the semantics of snapshots, and the difference between
   a hardlink and a reflink copy. You will need that later. Ask
   questions (detailed, targetted questions that show you know the
   difference between what you know and what you don't).

 * Read the developer documentation. Again, ask _useful_ questions
   (see below).

 * Improve userspace in some way. I'm serious about this -- it's less
   critical if something goes wrong, and we have more people who can
   review the patches while you're getting used to the code.

 * Then, and *only* then should you start digging into the kernel
   code. Read the developer documentation again. Use btrfs-debug-tree
   to inspect the contents of a filesystem and work out how it fits
   together. This is *not* optional. When you get to that point, and
   understand how the on-disk structures fit together, then we can
   talk more about suitable approaches for whatever code you want to
   write.

   Finally, on the subject of asking useful questions: Questions such
as "tell me where to start", or "how do you want me to write this?"
are bad, because they demonstrate that you have put in absolutely no
thought of your own. You don't have an opinion of your own, and you're
effectively acting as a completely passive element. This means that
you're a net time-sink, and with that attitude you're unlikely ever to
produce a positive overall effort in the project.

   Instead, you should be doing as much as you can to learn about the
system on your own. We have quite a lot of documentation on the
user-visible behaviour of the FS. We have documentation on data
structures. We have some documentation on the core tree-manipulation
functions. Read that, understand it. Look at the code and see how it's
implemented. Start asking _yourself_ the questions of "if I want to
achieve this effect, what does the FS need to do? What behaviour would
need to be changed, and how?". When you think you have an answer to
those questions, you can start having a real and useful conversation.
You will probably be wrong, but that's where the process starts, and
you will get better at it over time. If at some point there's
something you don't understand, do ask, but make sure that you can say
what you think you know, and why you can't understand the thing you
are having trouble with. Think of the person responding to the
question: Make it easy to write the reply by ensuring that the reply
can be as short as possible. Some of the time, you will actually
answer your own question by trying to ask it in a sensible way. If you
find that happening, you're asking sensible questions.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
           --- I must be musical:  I've got *loads* of CDs ---           

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: Help with Project on brtfs wiki

[Martin Steigerwald]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Hi Hugo,

Am Samstag, 26. Juli 2014, 11:05:03 schrieb Hugo Mills:
> > I am not asking to hold my hand
> 
>    You are, though. Something like using grep to find code that (might
> be) related to the thing you're trying to work with is _fundamental_.
> You should expect to be reading the code -- several layers deep, in
> both directions from any given function -- in order to understand what
> it does and how it fits in, and what problems you might enncounter if
> you change it. If you won't put in that degree of basic effort, then
> you won't get very far.

Actually, from what I read from Nick Krause so far here and on LKML:

Can it be that he is at admittedly quite inventive trolling?

I found none of his posts to be even remotely convincing although he submitted 
a patch elsewhere.

Thanks for your detailed explaination tough.


To Nick: If I am mistaken – mea culpa. But your posts just seem to follow what 
I perceive the usual style of something into trolling.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Help with Project on brtfs wiki

[Wang Shilong]

> Hi Hugo,
> 
> Am Samstag, 26. Juli 2014, 11:05:03 schrieb Hugo Mills:
>>> I am not asking to hold my hand
>> 
>>   You are, though. Something like using grep to find code that (might
>> be) related to the thing you're trying to work with is _fundamental_.
>> You should expect to be reading the code -- several layers deep, in
>> both directions from any given function -- in order to understand what
>> it does and how it fits in, and what problems you might enncounter if
>> you change it. If you won't put in that degree of basic effort, then
>> you won't get very far.
> 
> Actually, from what I read from Nick Krause so far here and on LKML:
> 
> Can it be that he is at admittedly quite inventive trolling?
> 
> I found none of his posts to be even remotely convincing although he submitted 
> a patch elsewhere.
> 
> Thanks for your detailed explaination tough.

Hugo is one of most reliable and serious man i have known.

Anyway, Nick if you really want to do something, just follow Hugo, Ted and others'
advices. Contributing Btrfs has many ways, try it and report some BUGs, add some
regression tests etc are all welcome IMO.

Thanks,
Wang
> 
> 
> To Nick: If I am mistaken – mea culpa. But your posts just seem to follow what 
> I perceive the usual style of something into trolling.
> 
> Ciao,
> -- 
> Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
> GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: Help with Project on brtfs wiki

[Nick Krause]

On Sat, Jul 26, 2014 at 7:07 AM, Wang Shilong <wangshilong1991@gmail.com> wrote:
>
>> Hi Hugo,
>>
>> Am Samstag, 26. Juli 2014, 11:05:03 schrieb Hugo Mills:
>>>> I am not asking to hold my hand
>>>
>>>   You are, though. Something like using grep to find code that (might
>>> be) related to the thing you're trying to work with is _fundamental_.
>>> You should expect to be reading the code -- several layers deep, in
>>> both directions from any given function -- in order to understand what
>>> it does and how it fits in, and what problems you might enncounter if
>>> you change it. If you won't put in that degree of basic effort, then
>>> you won't get very far.
>>
>> Actually, from what I read from Nick Krause so far here and on LKML:
>>
>> Can it be that he is at admittedly quite inventive trolling?
>>
>> I found none of his posts to be even remotely convincing although he submitted
>> a patch elsewhere.
>>
>> Thanks for your detailed explaination tough.
>
> Hugo is one of most reliable and serious man i have known.
>
> Anyway, Nick if you really want to do something, just follow Hugo, Ted and others'
> advices. Contributing Btrfs has many ways, try it and report some BUGs, add some
> regression tests etc are all welcome IMO.
>
> Thanks,
> Wang
>>
>>
>> To Nick: If I am mistaken – mea culpa. But your posts just seem to follow what
>> I perceive the usual style of something into trolling.
>>
>> Ciao,
>> --
>> Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
>> GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
>

Fine then I guess I need to read the documentation and other things on my own.
Seems everyone here wants me to figure out everything on my own.
Nick

Re: Help with Project on brtfs wiki

[Chris Murphy]

On Jul 26, 2014, at 7:43 PM, Nick Krause <xerofoify@gmail.com> wrote:

> On Sat, Jul 26, 2014 at 7:07 AM, Wang Shilong <wangshilong1991@gmail.com> wrote:
>> 
>>> Hi Hugo,
>>> 
>>> Am Samstag, 26. Juli 2014, 11:05:03 schrieb Hugo Mills:
>>>>> I am not asking to hold my hand
>>>> 
>>>>  You are, though. Something like using grep to find code that (might
>>>> be) related to the thing you're trying to work with is _fundamental_.
>>>> You should expect to be reading the code -- several layers deep, in
>>>> both directions from any given function -- in order to understand what
>>>> it does and how it fits in, and what problems you might enncounter if
>>>> you change it. If you won't put in that degree of basic effort, then
>>>> you won't get very far.
>>> 
>>> Actually, from what I read from Nick Krause so far here and on LKML:
>>> 
>>> Can it be that he is at admittedly quite inventive trolling?
>>> 
>>> I found none of his posts to be even remotely convincing although he submitted
>>> a patch elsewhere.
>>> 
>>> Thanks for your detailed explaination tough.
>> 
>> Hugo is one of most reliable and serious man i have known.
>> 
>> Anyway, Nick if you really want to do something, just follow Hugo, Ted and others'
>> advices. Contributing Btrfs has many ways, try it and report some BUGs, add some
>> regression tests etc are all welcome IMO.
>> 
>> Thanks,
>> Wang
>>> 
>>> 
>>> To Nick: If I am mistaken – mea culpa. But your posts just seem to follow what
>>> I perceive the usual style of something into trolling.
>>> 
>>> Ciao,
>>> --
>>> Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
>>> GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
>> 
> 
> Fine then I guess I need to read the documentation and other things on my own.

I don't see how it can work any other way, but my house plant disagrees and wishes to volunteer doing all of this for you. I don't recommend it because Btrfs developers do not need a smart aleck house plant writing kernel code.

> Seems everyone here wants me to figure out everything on my own.

By my reading, not everything, but rather specific things. You need a basic common frame of reference before questions and collaboration are workable. What's a car? Why do I need one? Where would I go? Roads? Wait there are other cars? Traffic signals? Insurance? Fuel? Oy this sounds complicated… I don't think I want or need one of these things.



Chris Murphy

Re: Help with Project on brtfs wiki

[Nick Krause]

On Sat, Jul 26, 2014 at 10:05 PM, Chris Murphy <lists@colorremedies.com> wrote:
>
> On Jul 26, 2014, at 7:43 PM, Nick Krause <xerofoify@gmail.com> wrote:
>
>> On Sat, Jul 26, 2014 at 7:07 AM, Wang Shilong <wangshilong1991@gmail.com> wrote:
>>>
>>>> Hi Hugo,
>>>>
>>>> Am Samstag, 26. Juli 2014, 11:05:03 schrieb Hugo Mills:
>>>>>> I am not asking to hold my hand
>>>>>
>>>>>  You are, though. Something like using grep to find code that (might
>>>>> be) related to the thing you're trying to work with is _fundamental_.
>>>>> You should expect to be reading the code -- several layers deep, in
>>>>> both directions from any given function -- in order to understand what
>>>>> it does and how it fits in, and what problems you might enncounter if
>>>>> you change it. If you won't put in that degree of basic effort, then
>>>>> you won't get very far.
>>>>
>>>> Actually, from what I read from Nick Krause so far here and on LKML:
>>>>
>>>> Can it be that he is at admittedly quite inventive trolling?
>>>>
>>>> I found none of his posts to be even remotely convincing although he submitted
>>>> a patch elsewhere.
>>>>
>>>> Thanks for your detailed explaination tough.
>>>
>>> Hugo is one of most reliable and serious man i have known.
>>>
>>> Anyway, Nick if you really want to do something, just follow Hugo, Ted and others'
>>> advices. Contributing Btrfs has many ways, try it and report some BUGs, add some
>>> regression tests etc are all welcome IMO.
>>>
>>> Thanks,
>>> Wang
>>>>
>>>>
>>>> To Nick: If I am mistaken – mea culpa. But your posts just seem to follow what
>>>> I perceive the usual style of something into trolling.
>>>>
>>>> Ciao,
>>>> --
>>>> Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
>>>> GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
>>>
>>
>> Fine then I guess I need to read the documentation and other things on my own.
>
> I don't see how it can work any other way, but my house plant disagrees and wishes to volunteer doing all of this for you. I don't recommend it because Btrfs developers do not need a smart aleck house plant writing kernel code.
>
>> Seems everyone here wants me to figure out everything on my own.
>
> By my reading, not everything, but rather specific things. You need a basic common frame of reference before questions and collaboration are workable. What's a car? Why do I need one? Where would I go? Roads? Wait there are other cars? Traffic signals? Insurance? Fuel? Oy this sounds complicated… I don't think I want or need one of these things.
>
>
>
> Chris Murphy
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

That's fine I don't find :). Sorry about being lazy in advance, bad habits.
Cheers Nick

Re: Help with Project on brtfs wiki

[Eric Sandeen]

On 7/26/14, 8:43 PM, Nick Krause wrote:

...

> Fine then I guess I need to read the documentation and other things on my own.
> Seems everyone here wants me to figure out everything on my own.

Hugo bent over backwards, twice, to give you very good advice.  So did
Steven Rostedt on LKML.  You should follow it, and see how things go
from there.

-Eric

> Nick