From: Chuck Lever <chuck.lever@oracle.com>
Subject: Re: umount fails with device busy
Date: Thu, 23 Aug 2007 16:35:28 -0400
Message-ID: <46CDEF90.90007@oracle.com>
References: <20070823184544.237460@gmx.net> <46CDE805.4090909@oracle.com>
	<46CDEE3A.3040809@redhat.com>
Reply-To: chuck.lever@oracle.com
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="------------010307080600050902080903"
Cc: nfs@lists.sourceforge.net
To: Peter Staubach <staubach@redhat.com>
In-Reply-To: <46CDEE3A.3040809@redhat.com>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

This is a multi-part message in MIME format.
--------------010307080600050902080903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>>> When I run umount during these ops I get an device busy. Any help 
>>> would be very appreciated!
>>
>> This is normal and expected behavior.  One problem may be that your 
>> server is slow, and thus there are RPCs left outstanding for a bit on 
>> your client after your application exits.  The COMMIT calls from that 
>> trace suggest that there is dirty data the client is writing back to 
>> the server. 
> 
> It seems to me that this should not be the expected behavior unless
> the file system is mounted "nocto".  Is it?

I'm a little puzzled myself about what dirty data there might be left 
after the application quits.  However, I'll be there is an mmap() 
lurking somewhere in the background...

Data that was dirtied via a mapped file is not subject to the writeback 
part of close-to-open.

--------------010307080600050902080903
Content-Type: text/x-vcard; charset=utf-8;
 name="chuck.lever.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="chuck.lever.vcf"

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


--------------010307080600050902080903
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
--------------010307080600050902080903
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

--------------010307080600050902080903--