[CentOS] Fwd: Bug 800181: NFSv4 on RHEL 6.3 over six times slower than 5.8

[Colin Simpson]

We have this issue.

I have a support call open with Red Hat about it. Bug reports will only
really forcibly get actioned if you open a support call and point at the
bug report.

I also have this issue though much much worse on Fedora (using BTRFS),
which will surely have to be fixed before BTRFS becomes the default fs
in RHEL. But the Fedora bug I have open on this provided some useful
insights on NFSv4 esp :

https://bugzilla.redhat.com/show_bug.cgi?id=790232#c2

Particularly:

"NFS file and directory creates are synchronous operation: before the
create can return, the client must get a reply from the server saying
not only that it has created the new object, but that the create has
actually hit the disk."

Also listed here is a proposed protocol extension to NFS v4 to make file
creation more efficient:

http://tools.ietf.org/html/draft-myklebust-nfsv4-unstable-file-creation-01

Not sure if this will be added to RH.

Also RH support found:

http://archive09.linux.com/feature/138453

"NFSv4 file creation is actually about half the speed of file creation
over NFSv3, but NFSv4 can delete files quicker than NFSv3. By far the
largest speed gains come from running with the async option on, though
using this can lead to issues if the NFS server crashes or is rebooted."

I'm glad we aren't the only ones seeing this, it sort of looked like we
were when talking to support!

I'll add this RH bug number to my RH support ticket.

But think yourself lucky, BTRFS on Fedora 16 was much worse. This was
the time it took me to untar a vlc tarball.

F16 to RHEL5 - 0m 28.170s
F16 to F16 ext4 -  4m 12.450s
F16 to F16 btrfs - 14m 31.252s

A quick test seems to say this is better in F17 (3m7.240s on BTRFS but
still looks like we are hitting NFSv4 issues for this but btrfs itself
is better).

Thanks

Colin

On Tue, 2012-07-10 at 15:58 -0700, an unknown sender wrote:
> It may not be a bug, it may be that RHEL 6.x implements I/O barriers
> correctly, which slows things down but keeps you from losing data....
>
>
> On Tue, Jul 10, 2012 at 7:18 AM,  <m.roth at 5-cent.us> wrote:
> > Thought I'd post this here, too - I emailed it to the redhat list, and
> > that's pretty moribund, while I've seen redhatters here....
> >
> > ---------------------------- Original Message ----------------------------
> > Subject: Bug 800181: NFSv4 on RHEL 6.2 over six times slower than 5.7
> > From:    m.roth at 5-cent.us
> > Date:    Tue, July 10, 2012 09:54
> > To:      "General Red Hat Linux discussion list" <redhat-list at redhat.com>
> > --------------------------------------------------------------------------
> >
> > m.roth at 5-cent.us wrote:
> >> For any redhatters on the list, I'm going to be reopening this bug today.
> >>
> >> I am also VERY unhappy with Redhat. I filed the bug months ago, and it was
> >> *never* assigned - no one apparently even looked at it. It's a
> >> show-stopper for us, since it hits us on our home directory servers.
> >>
> >> A week or so ago, I updated our test system to 6.3, and *nothing* has
> >> changed. Unpack a large file locally, and it's seconds. Unpack from an
> >> NFS-mounted directory to a local disk takes about 1.5min. NFS mount either
> >> an ext3 or ext4 fs, cd to that directory, and I run a job to unpack a
> >> large file to the NFS-mounted directory, and it's between 6.5 and 7.5
> >> *MINUTES*. We cannot move our home directory servers to 6.x with this
> >> unacknowledged ->BUG<-.
> >>
> >> Large file is defined as a 28M .gz file, unpacked to 92M.
> >>
> >> This is 100% repeatable.
> >>
> >> I tried sending an email to our support weeks ago, and got no response.
> >> Maybe it takes shaming in a public forum to get anyone to acknowledge this
> >> exists....
> >>
> >           mark
> >
> >
> >
> > _______________________________________________
> > CentOS mailing list
> > CentOS at centos.org
> > http://lists.centos.org/mailman/listinfo/centos
>
>
>


________________________________


This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.