Skip to contentSkip to conversation

ltp stress test for RHEL5 and NFS local mount

LTP gchen 2 participants 3 messages Sep 2, 2012 – Sep 4, 2012

lore
Share & tools
lore

gchen

author
#0 lore raw

Hello [email protected]

Question:

Use ltp stress test (/opt/ltp/ltpstress.sh) with ltp-full-20100331.gz to test RHEL5 (kernel-2.6.18-308.4.1.el5) for 72 hours.

Not give any more configurations for NFS (using default configuration:
mount NFS locally, so the NFS client and NFS server are on the same machine).

My question is that "for stress test, is it suitable to let NFS server and client on the same machine ?"

Background;

This configuration will cause deadlock for RHEL5, and can not boot machine in normal way.

someone from Red Hat has said that:
--------------------------------------------------------------------------------------------------------------

"Have configuration where the same host is acting as both NFS client and server. That's a configuration known to cause deadlocks."

--------------------------------------------------------------------------------------------------------------

can reference Red Hat Bugzilla (bug 848706) for more details.

thanks.

gchen.

Asianux Corporation.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

#1 lore raw
Quoted 24 lines · gchen

Hello [email protected]

Question:

Use ltp stress test (/opt/ltp/ltpstress.sh) with ltp-full-20100331.gz to test RHEL5 (kernel-2.6.18-308.4.1.el5) for 72 hours.

Not give any more configurations for NFS (using default configuration:
mount NFS locally, so the NFS client and NFS server are on the same machine).

My question is that "for stress test, is it suitable to let NFS server and client on the same machine ?"

Background;

This configuration will cause deadlock for RHEL5, and can not boot machine in normal way.

someone from Red Hat has said that:
--------------------------------------------------------------------------------------------------------------

Quoted 6 lines

"Have configuration where the same host is acting as both NFS client and server. That's a configuration known to cause deadlocks."

--------------------------------------------------------------------------------------------------------------

can reference Red Hat Bugzilla (bug 848706) for more details.

I've done that occasionally on FreeBSD (mount over nfs into a
chroot) before I discovered nullfs (sort of like the unionfs equivalent on *BSD), but I didn't stress the system. It's an interesting scenario, but I would say that this is more of a fringe case than something that one would normally do.
If it helps you better isolate an issue that occurs in scenarios
where the NFS client/server are separate from one another, I'd say go for it.
Cheers,
-Garrett

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

author
#2 lore raw
Quoted 31 lines · Garrett Cooper
Quoted 24 lines · gchen

Hello [email protected]

Question:

Use ltp stress test (/opt/ltp/ltpstress.sh) with ltp-full-20100331.gz to test RHEL5 (kernel-2.6.18-308.4.1.el5) for 72 hours.

Not give any more configurations for NFS (using default configuration:
mount NFS locally, so the NFS client and NFS server are on the same machine).

My question is that "for stress test, is it suitable to let NFS server and client on the same machine ?"

Background;

This configuration will cause deadlock for RHEL5, and can not boot machine in normal way.

someone from Red Hat has said that:
--------------------------------------------------------------------------------------------------------------

Quoted 6 lines

"Have configuration where the same host is acting as both NFS client and server. That's a configuration known to cause deadlocks."

--------------------------------------------------------------------------------------------------------------

can reference Red Hat Bugzilla (bug 848706) for more details.

Quoted 12 lines

I've done that occasionally on FreeBSD (mount over nfs into a
chroot) before I discovered nullfs (sort of like the unionfs equivalent on *BSD), but I didn't stress the system. It's an interesting scenario, but I would say that this is more of a fringe case than something that one would normally do.
If it helps you better isolate an issue that occurs in scenarios
where the NFS client/server are separate from one another, I'd say go for it.
Cheers,
-Garrett

Thank you for your reply.

It will be better if I can get more confirmation from LTP mailing list.

I think;
If we use /opt/ltp/testscript/ltpstress.sh directly, it will use NFS local mount for stress test.

If no additional reply within this week, I will believe the conclusion from Red Hat:

Signature · 15 lines
Chen Gang

Asianux Corporation


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list