DENIEL Philippe [philippe.deniel@xxxxxx] 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
