Skip to contentSkip to conversation

How to manage EDQUOT on the server side

DISCUSSION DENIEL Philippe 2 participants 4 messages Apr 12, 2012

Subsystems (2)
NFS client NFS server
lore
Share & tools
lore

DENIEL Philippe

author
#0 lore raw

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

#1 lore raw

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.

Quoted 21 lines · 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

author
#2 lore raw
Quoted 1 line · Malahal Naineni

Are you using Linux client?

Yes.

Quoted 3 lines

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

Quoted 34 lines

I didn't know about client looping on the same WRITE call though!

Thanks, Malahal.

Quoted 13 lines · 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 ?

Quoted 9 lines

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

#3 lore raw
Quoted 4 lines · DENIEL Philippe [[email protected]] wrote:
Quoted 2 lines

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.