NFS why root=nfs and root=nfs4?

NFS why root=nfs and root=nfs4?

[Warren Togami]

I just realized that the following are yet another NFS syntax variation.

     client_test "NFSv3 root=nfs DHCP path only" 52:54:00:12:34:00 \
         "root=nfs" 192.168.50.1 -wsize=4096 || return 1

     client_test "NFSv3 root=nfs DHCP IP:path" 52:54:00:12:34:01 \
         "root=nfs" 192.168.50.2 -wsize=4096 || return 1

     client_test "NFSv4 root=nfs4 DHCP path only" 52:54:00:12:34:80 \
         "root=nfs4" 192.168.50.1 -wsize=4096 || return 1

     client_test "NFSv4 netroot=nfs4 DHCP IP:path" 52:54:00:12:34:81 \
         "netroot=nfs4" 192.168.50.2 -wsize=4096 || return 1

     client_test "NFSv4 root=nfs4 DHCP IP:path" 52:54:00:12:34:81 \
         "root=nfs4" 192.168.50.2 -wsize=4096 || return 1

     client_test "NFSv4 root=nfs4" 52:54:00:12:34:84 \
         "root=nfs4" 192.168.50.1 -wsize=4096 || return 1

     client_test "NFSv4 root=nfs4 DHCP path,options" \
         52:54:00:12:34:85 "root=nfs4" 192.168.50.1 wsize=4096 || return

     client_test "NFSv4 root=nfs4 DHCP IP:path,options" \
         52:54:00:12:34:86 "root=nfs4" 192.168.50.2 wsize=4096 || return

When is it ever necessary to use explicitly root=nfs or root=nfs4 
instead of root=dhcp?  It seems functionally equivalent while 
unnecessarily limiting since DHCP should tell you the protocol.

Benefits of de-supporting these variations:
* Simplify the documentation further, fewer possible ways to configure 
it to confuse people.
* Far fewer redundant test cases to make the test suite slow.

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFS why root=nfs and root=nfs4?

[David Dillow]

On Mon, 2009-06-22 at 17:31 -0400, Warren Togami wrote:
> I just realized that the following are yet another NFS syntax variation.
> 
>      client_test "NFSv3 root=nfs DHCP path only" 52:54:00:12:34:00 \
>          "root=nfs" 192.168.50.1 -wsize=4096 || return 1
[snip]
> When is it ever necessary to use explicitly root=nfs or root=nfs4 
> instead of root=dhcp?  It seems functionally equivalent while 
> unnecessarily limiting since DHCP should tell you the protocol.

Sigh. Let's have this conversation again.

The kernel nfsroot support allows root=/dev/nfs to get the root path
information from DHCP instead of nfsroot. We support that legacy syntax.

root=nfs was a shortcut to root=/dev/nfs
root=nfs4 was a shortcut to root=/dev/nfs4, which is something I made up
when adding nfsroot support to dracut, as it seemed to have a certain
symmetry with the kernel's support for NFSv3.

You were planning on removing root=nfs, root=nfs4, and root=/dev/nfs4,
leaving only root=/dev/nfs for compatibility with the kernel, so the
root=nfs tests would need to be converted to root=/dev/nfs and the rest
would go away in that case.

> Benefits of de-supporting these variations:
> * Simplify the documentation further, fewer possible ways to configure 
> it to confuse people.

Have a standard syntax section that only mentions the way we want to
have people use the software, and have a Legacy (and possibly Expert)
section that gives other ways that work, with a note that these are not
the suggested/preferred ways.

Am I missing something that makes this so hard? Or do I just have a
kinder opinion of users than others around here?


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFS why root=nfs and root=nfs4?

[Warren Togami]

On 06/22/2009 06:41 PM, David Dillow wrote:
> On Mon, 2009-06-22 at 17:31 -0400, Warren Togami wrote:
>> I just realized that the following are yet another NFS syntax variation.
>>
>>       client_test "NFSv3 root=nfs DHCP path only" 52:54:00:12:34:00 \
>>           "root=nfs" 192.168.50.1 -wsize=4096 || return 1
> [snip]
>> When is it ever necessary to use explicitly root=nfs or root=nfs4
>> instead of root=dhcp?  It seems functionally equivalent while
>> unnecessarily limiting since DHCP should tell you the protocol.
>
> Sigh. Let's have this conversation again.
>
> The kernel nfsroot support allows root=/dev/nfs to get the root path
> information from DHCP instead of nfsroot. We support that legacy syntax.
>
> root=nfs was a shortcut to root=/dev/nfs
> root=nfs4 was a shortcut to root=/dev/nfs4, which is something I made up
> when adding nfsroot support to dracut, as it seemed to have a certain
> symmetry with the kernel's support for NFSv3.

With all due respect, I was hesitant to suggest strongly on this earlier 
because it was against your opinion and you have been an important 
contributor to this project.  It is of my opinion that having too many 
ways of configuring the same behavior has too many drawbacks.  For 
brevity I will not restate the many reasons why the Legacy nfsroot.txt 
syntax is deprecated and it makes even less sense to invent additional 
shortcuts that immediately become deprecated as well.

It is a different story if a syntax variation exists because it is 
impossible to do something without it.

If I had it my way, I would advocate dropping Legacy entirely including 
the nfsroot.txt syntax and all netboot syntaxes supported (poorly) by 
mkinitrd.  However it seems that a reasonable compromise is to tolerate 
this particular legacy syntax because it is supported well by Debian's 
initramfs-tools.

>
> You were planning on removing root=nfs, root=nfs4, and root=/dev/nfs4,
> leaving only root=/dev/nfs for compatibility with the kernel, so the
> root=nfs tests would need to be converted to root=/dev/nfs and the rest
> would go away in that case.

I was uncertain about removal of cases that did not explicitly involve 
"nfsroot=", if it remained fully feature-wise capable after that.  I 
guess it does now.

>
>> Benefits of de-supporting these variations:
>> * Simplify the documentation further, fewer possible ways to configure
>> it to confuse people.
>
> Have a standard syntax section that only mentions the way we want to
> have people use the software, and have a Legacy (and possibly Expert)
> section that gives other ways that work, with a note that these are not
> the suggested/preferred ways.
>
> Am I missing something that makes this so hard? Or do I just have a
> kinder opinion of users than others around here?

This is a difference in design philosophy.  We have a native syntax that 
seems fully feature capable.  Allowing redundancy and variation in this 
syntax can confuse people less technically savvy than us who follow 
documentation and examples.

A strong argument against this is only if it can be pointed out that a 
feature is not capable under the native syntax.

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFS why root=nfs and root=nfs4?

[David Dillow]

On Mon, 2009-06-22 at 21:16 -0400, Warren Togami wrote:
> On 06/22/2009 06:41 PM, David Dillow wrote:
> > root=nfs was a shortcut to root=/dev/nfs
> > root=nfs4 was a shortcut to root=/dev/nfs4, which is something I made up
> > when adding nfsroot support to dracut, as it seemed to have a certain
> > symmetry with the kernel's support for NFSv3.
> 
> With all due respect, I was hesitant to suggest strongly on this earlier 
> because it was against your opinion and you have been an important 
> contributor to this project.  It is of my opinion that having too many 
> ways of configuring the same behavior has too many drawbacks.  For 
> brevity I will not restate the many reasons why the Legacy nfsroot.txt 
> syntax is deprecated and it makes even less sense to invent additional 
> shortcuts that immediately become deprecated as well.

You'll notice I wasn't arguing to keep them -- I was answering your
question about why they exist. I've already given up on root=nfs[4] and
root=/dev/nfs4. While I am not in complete agreement, you at least have
a point that we shouldn't make up new ways in addition to our preferred
syntax and I'm tired of kicking that particular horse.

As for the many reasons nfsroot.txt syntax is deprecated, I can only
think of three that you have mentioned:
1) User confusion
2) Code complexity
3) Kernel-only support

We currently disagree on user confusion, and I think Phillipe and I have
shown that it need not add large amounts of complexity to translate the
legacy syntax into our preferred one. And you mentioned that debian
emulates the syntax.

Are there others? I apologize if you went over this before, as I dislike
asking other to repeat themselves as much as I like doing it myself. But
those are the reasons I found on the mailing list, and since my house
lost power while I was on vacation, my IRC logs are gone.

> If I had it my way, I would advocate dropping Legacy entirely including 
> the nfsroot.txt syntax and all netboot syntaxes supported (poorly) by 
> mkinitrd.  However it seems that a reasonable compromise is to tolerate 
> this particular legacy syntax because it is supported well by Debian's 
> initramfs-tools.

You've been advocating this even if you don't have it your way. ;)

I'll bow down to a good argument, or to consensus of the project if
there's no compelling argument either way. Get Harald to say they need
to go after hearing both sides and I'll help rip them out.

But if you don't mind, that discussion should happen here on the list.
While IRC is a good place to discuss details and brainstorm, policy
discussions need to have a more permanent record; making those kind of
decisions via IRC excludes those who happen to not be in the room at the
right time, and offers no insight as to why things are the way they are
to late comers to the project.

> This is a difference in design philosophy.  We have a native syntax that 
> seems fully feature capable.  Allowing redundancy and variation in this 
> syntax can confuse people less technically savvy than us who follow 
> documentation and examples.

The people that do "config by example" are going to find the old HOWTOs
that discuss using nfsroot.txt syntax. A current search for "linux nfs
root" returns the NFS-root mini-HOWTO (circa 1996) and
Diskless-root-NFS-other-HOWTO (circa 2001) as the top two results. In
fact 5 of the top 6 results refer to the nfsroot.txt syntax and the
sixth one refers one to the NFS-root mini-HOWTO for the kernel command
line setup.

Now, some of those also talk about configuring and compiling your kernel
to support NFS root, which if followed means dracut would not be used.
But I've known more than one config-by-example person that would just
try the command line argument on the assumption the the distro kernel
would have that built in. I do not know the percentage of the population
that would do this, so I don't know which way the argument cuts.

> A strong argument against this is only if it can be pointed out that a 
> feature is not capable under the native syntax.

Another one is if the examples they are going to find are going to be
the legacy ones.

In the HOWTO, README. and examples we provide, we should describe and
show the preferred method, and point to a different section that
documents the legacy methods, but marks them clearly as such. No
examples need be given, as if you are using the legacy methods you
should know what they look like.

I've put this idea forward a few times now, and it seems to get ignored
or brushed aside with hand-waving. If it won't work, give me some
reasoned discussion as to why. I don't buy that the users are going to
be confused by all the legacy syntax variants because as I've shown
above, that's the examples I expect they will find.

Or is this both of us arguing from our gut and we'll have to disagree
until Harald lays down the law about syntactic support?


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFS why root=nfs and root=nfs4?

[Warren Togami]

On 06/22/2009 11:48 PM, David Dillow wrote:
>> This is a difference in design philosophy.  We have a native syntax that
>> seems fully feature capable.  Allowing redundancy and variation in this
>> syntax can confuse people less technically savvy than us who follow
>> documentation and examples.
>
> The people that do "config by example" are going to find the old HOWTOs
> that discuss using nfsroot.txt syntax. A current search for "linux nfs
> root" returns the NFS-root mini-HOWTO (circa 1996) and
> Diskless-root-NFS-other-HOWTO (circa 2001) as the top two results. In
> fact 5 of the top 6 results refer to the nfsroot.txt syntax and the
> sixth one refers one to the NFS-root mini-HOWTO for the kernel command
> line setup.

Isn't arguing over this moot?  I already said this is a reasonable 
compromise because of the upstream kernel and initramfs-tools.

None of those other documents however will have root=nfs, root=nfs4 or 
root=/dev/nfs4 examples.  I object to more confusing variations like 
this redundant to the preferred, full featured native syntax.

> Or is this both of us arguing from our gut and we'll have to disagree
> until Harald lays down the law about syntactic support?
>

Harald was in favor of removing the three "shortcut" variations of 
Legacy nfsroot.txt.  He also said I could go ahead and eliminate the 
netroot= variations if I felt strongly about it.  I do hope he would 
make his own comments on this matter.

I will still push chopping either root= or netroot= NFS variations, but 
only after we see what Harald decides to do for DHCP root-path for 
remote block devices (his iscsi idea).

Warren Togami
wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html