Bug 80018: NFSv4 on RHEL 6.2 over six times slower than 5.7

[Corey Kovacs]

TAM = Technical Account Manager.

I asked about auditing and you asked about selinux auditing. Since when is
selinux auditing? I mean the auditd daemon. It can tax the system severely
if not set up correctly.

I asked about your exports file, you give me the format for a generic
exports file. If you didn't notice, i am an RHCA. I think I know what the
general format is.

I asked about kerberos, you said you didn't know..  how can you NOT know if
you are using kerberos?

I asked you to give us something to work with. You said "read the damn
bug". I did, it's so fricking vague it's ridiculous.

You seem to have very little information/knowledge of your system which
isn't too surprising at this point.

So, you seem to have decided to be very unproessional about this, so I say
good luck. I will not respond to you again. I can only hope others don't
either.


Have fun....


On Tue, Jul 10, 2012 at 8:47 PM, mark <m.roth at 5-cent.us> wrote:

> On 07/10/12 20:41, Corey Kovacs wrote:
>
>> Well, looking at the Bugzilla, it looks like they are asking you to
>> contact
>> your support rep. If you are working in the government, there will be a
>> TAM
>>
>
> I'm waiting for my manager to tell me how to file. I have no idea what a
> TAM is - we do all this ourselves.
>
>
>  assigned to handle these problems. If you are a contractor working on
>> systems to be delivered to the government, then you need to be a paying
>> customer to expect support from Red Hat. Especially when your original
>> problem manifested on CentOS. Granted, it's the same code base, but that
>> doesn't make your problem on CentOS, a problem for Red Hat.
>>
>
> I'll say it one more time: we found the problem on CentOS. We went to our
> test RHEL system. Updated it. Exported a directory *from* the RHEL box to
> itself, to /mnt/foo, and ran the test, and got the same results.
>
> In fact, I ran it twice today, updating the kernel in between, and with
> 6.3, it's taking a consistent 7.5 min, instead of the 6.5 we were getting
> with 6.2
> <snip>
>
>  Now, all that said and done, here are some questions for you which might
>> help us figure what would help.
>>
>> 1. What options are present on the mount? (cat /proc/mounts, thinks like
>> sync can be a problem)
>>
>
> I"m not at work. I'll have to answer that in the morning. I will tell you
> that when we were first trying to figure it out, two months ago, I did try
> no sync.
>
>
>  2. What does your /etc/exports config look like on your server node (cat
>> /etc/exports)
>>
>
> /scratch/foo <servername>: options
>
>
>  3. You are using NFSv4, are you using Kerberos with it?
>>
>
> I don't believe we have kerborous set with NFS. We do use it for other
> things.
>
>
>       3.a. If so, what mode are you using for your gss/krb flag? (krb5,
>> krb5i, krb5p)
>> 4. What's your network speed? Are you sure? (ethtool ethX to make sure)
>>
>
> Gigabit.
>
>  5. Selinux?
>>
> Permissive.
>
>  6. Auditing?
>>
>
> Do you mean selinux auditing? As I said, doing it on the local drive takes
> seconds. Doing it from a 5.x NFS server takes about 1.5 min. Therefore,
> there's nothing that could affect it on the one server.
>
>
>  7. How many clients are hitting your server and how many nfsd threads are
>> you running on it?
>>
>
> No other clients. This is a test system.
>
>
>> This is by no means an exhaustive list of things to look at.
>>
>> Anyway, in order to get any real help, you cannot just shout out, "My
>> stuff
>> is broke, it's Red Hat's fault, no one will listen to me!"
>>
>> Give us something to work with.
>>
>
> Try reading the damn bug.
>
>
>
>> By the way, in looking at the responses to your bugzilla, it doesn't look
>> to me like they were shamed into responding. It looks like are telling you
>> to go through proper channels if they exist. full stop.
>>
>
> No, they gave *ZERO* responses until today. The one and only response
> before today was, "oh, we're up to 6.3, we'll not even look at it".
>
> And my manager, who's a fed, and I, a contractor, along with the other
> admin under him, who is also a contractor, handle the licenses, etc, so
> there's no one else to wait for.
>
>
>         mark
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@**redhat.com<redhat-list-request at redhat.com>
> ?subject=unsubscribe
> https://www.redhat.com/**mailman/listinfo/redhat-list<https://www.redhat.com/mailman/listinfo/redhat-list>
>