How to manage EDQUOT on the server side

How to manage EDQUOT on the server side

[DENIEL Philippe]

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

Re: How to manage EDQUOT on the server side

[Malahal Naineni]

Are you using Linux client? I think there is a bug where the client
reports EIO rather than QUOTA/NOSPC errors under some circumstances.

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
> 

Re: How to manage EDQUOT on the server side

[DENIEL Philippe]

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
>   

Re: How to manage EDQUOT on the server side

[Malahal Naineni]

DENIEL Philippe [philippe.deniel@cea.fr] wrote:
> > 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.

For me dd with "conv=fdatasync" didn't work every time. Regular dd did
work, so the issue is with fsync/sync.

elm3c46:/mnt # dd if=/dev/zero of=./testfile count=100000 bs=1024
dd: closing output file `./testfile': No space left on device

elm3c46:/mnt # dd if=/dev/zero of=./testfile count=100000 bs=1024 conv=fdatasync
dd: fdatasync failed for `./testfile': Input/output error
100000+0 records in
100000+0 records out
102400000 bytes (102 MB) copied, 0.165134 s, 620 MB/s

Notes from Neil Brown:

The problem here is that vfs_sync_range in fs/sync.c prefers to error
from filemap_write_and_wait_range over the error from fop->fsync.

The former will be EIO in this case, the latter is EDQUOT.
fsync returns and error and then clears, so the EDQUOT is lost.

Shortly after this, nfs_do_fsync is called (again) which would prefer
the EDQUOT error, but it has been cleared by this time.

This only affect O_SYNC writes.

Regards, Malahal.
Neil's fix does work for my case.