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
DENIEL Philippe [[email protected]] 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.
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 [[email protected]] 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 [email protected]
>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 [[email protected]] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>