Message-ID: <4F86E813.3010200@cea.fr>
Date: Thu, 12 Apr 2012 16:34:59 +0200
From: DENIEL Philippe <philippe.deniel@cea.fr>
MIME-Version: 1.0
To: NFS list <linux-nfs@vger.kernel.org>
Subject: Re: How to manage EDQUOT on the server side
References: <4F86E4E0.8000703@cea.fr> <20120412142946.GB29891@us.ibm.com>
In-Reply-To: <20120412142946.GB29891@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: linux-nfs-owner@vger.kernel.org

Malahal Naineni a ?crit :
> Are you using Linux client?
Yes.

>  I think there is a bug where the client
> reports EIO rather than QUOTA/NOSPC errors under some circumstances.
>   
Do you have more informations about those circumstances ? I just ran 
"dd" until I exceed my data quota's hard limit.

    Regards

       Philippe

> I didn't know about client looping on the same WRITE call though!
>
> Thanks, Malahal.
>
> DENIEL Philippe [philippe.deniel@cea.fr] wrote:
>   
>> Hi,
>>
>> I am currently busy with implementing quota management in my nfs
>> server (nfs-ganesha).
>> I have efficient way to make NFS3_WRITE detecting an IO that exceeds
>> data quota, and use that to return NFS3ERR_DQUOT.
>> Wireshark shows me that nfs reply contains NFS3ERR_DQUOT, but the
>> client starts looping on the same WRITE call. By the end, by test
>> application (a simple 'dd') end with "I/O Error".
>> Did I miss something when implementing this ?
>> I had no rquotad running for the share at the time the test was
>> running, should I have a co-related rquotad running as well ?
>>
>>    Regards
>>
>>       Philippe
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>     
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>