Bug 472778

Summary: RHEL 5.2: /proc/mounts cluttered when using NFS&snapshots on NetApp NAS
Product: Red Hat Enterprise Linux 5 Reporter: Ondrej Valousek <ondrejv>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2CC: ikent, rwheeler, steved, yanwang
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-16 12:09:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Example of /proc/mounts when this happens
none
Example of /etc/mtab when this happens none

Description Ondrej Valousek 2008-11-24 15:24:21 UTC 
Description of problem:
/proc/mounts gets cluttered when browsing snapshots on NFS mounted volume from NetappNAS

Version-Release number of selected component (if applicable):
affects all recent 2.6.18 kernels, it does not affect 2.6.8 kernel line (RHEL-4). Also, NFSv4 mounted volumes are not affected.

How reproducible:
always

Steps to Reproduce:
1. mount a NFS share from NetApp NAS.
2. Enter snapshots directory (usually .snapshot) and browse via "ls -alR"
3. see the messy /proc/mounts
  
Actual results:
/proc/mounts get messed up with record for every single directory in that snapshots.
Gnome-VFS is relying on /proc/mounts and is it gets too big Gnome-VFS stops responding and all Gnome session freezes on the affected machine.

Expected results:
/proc/mounts should be possible left intact by this (ls -laR) operation.

Additional info:
It only affect NFSv3 mounted volumes, not NFSv4.
Comment 1 Steve Dickson 2008-11-25 16:00:34 UTC 
What do you mean by "gets cluttered"? Could you post an example?
Comment 2 Ian Kent 2008-11-25 16:04:31 UTC 
Created attachment 324624 [details]
Example of /proc/mounts when this happens

After discussing this with Ondrej I asked for examples of /proc/mounts and /etc/mtab and here they are.
Comment 3 Ian Kent 2008-11-25 16:05:43 UTC 
Created attachment 324625 [details]
Example of /etc/mtab when this happens

And here is /etc/mtab.
Comment 4 Ondrej Valousek 2008-11-26 15:35:41 UTC 
Update:
According to this:
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb44598
is what we see an expected (and correct) behavior. The NFS client in 2.6.9 is not behaving correctly (according to this).

Which means that there is a bug in RHEL5 kernels which prevents the internally mounted filesystems (forced by a different FSID) to be automatically unmounted (after timeout). I see this has been fixed in 2.8.24. Can we have this backported into RHEL5 please?

Thanks,
Ondrej
Comment 8 Ian Kent 2009-02-14 02:46:00 UTC 
(In reply to comment #4)
> Update:
> According to this:
> https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb44598
> is what we see an expected (and correct) behavior. The NFS client in 2.6.9 is
> not behaving correctly (according to this).
> 
> Which means that there is a bug in RHEL5 kernels which prevents the internally
> mounted filesystems (forced by a different FSID) to be automatically unmounted
> (after timeout). I see this has been fixed in 2.8.24. Can we have this
> backported into RHEL5 please?

I can't seem to see anything between RHEL 2.6.18 and vanilla 2.6.24
that looks like it relates to this. What information do you have
regarding this?
Comment 9 Ondrej Valousek 2009-02-16 08:44:39 UTC 
I can not replicate this reliably - possibly something to do with my local configuration. Not a bug. Sorry for wasting your time. Can you close this issue (can not do it myself)? Thanks. Ondrej
Comment 10 Ian Kent 2009-02-16 12:09:37 UTC 
(In reply to comment #9)
> I can not replicate this reliably - possibly something to do with my local
> configuration. Not a bug. Sorry for wasting your time. Can you close this issue
> (can not do it myself)? Thanks. Ondrej

Right, and I couldn't see anything that looked related.
So, if there is an issue, it's likely much more subtle
which would be much harder to port or even identify the
bits needed.

If you get more information, please re-open this bug.
Ian