Re: NFS over-quota not detected if utimes() called before fsync()/close()
In article 20130731222303.gj96...@trav.math.uni-bonn.de, Edgar Fuß e...@math.uni-bonn.de wrote: Yes, I believe you are right. Return an error for all errors. Any idea what the intent of only catching EINTR was? The flawed logic of: If the write fails for any other reason than being unterrupted by the user, why at least not succeed changing the permissions? christos
re: NFS over-quota not detected if utimes() called before fsync()/close()
On Sat, 06 Jul 2013, Manuel Bouyer wrote: But I would expect close() to do an implicit fsync() as well, and return the error if the implicit fsync() didn't succeed (but still closing the file). As I already mentionned, linux behaves this way, and I guess applications expects this behavior. I would not expect close() to implicitly fsync() the file, and I do not think that NetBSD does so. If the application wants fsync-like behaviour then I think the application should call fsync(). close(2) on an NFS file system will (should), at the very least, cause the server to attempt to allocate the specified blocks that are currently unwritten. if this fails (for say, quota or disk full errors), then then only way this is signaled to the application is via close(2) failure. in general any application that does not check close(2) for failure and if present, understand any writes to this file may have failed. (this is particular relevant for mail servers.) .mrg.
Re: NFS over-quota not detected if utimes() called before fsync()/close()
On Jul 31, 2013, at 10:04 PM, Christos Zoulas chris...@astron.com wrote: In article 20130730211200.gd96...@trav.math.uni-bonn.de, Edgar Fuß e...@math.uni-bonn.de wrote: I think the problem is in nfs_setattr(), sys/nfs/nfs_vnops.c:681, where files are flushed before setattr because a later write of cached data might change timestamps or reset sugid bits, but the only return value of nfs_vinvalbuf() that's treated as an error is EINTR. Why? Any comments on this? We are losing mail because of this problem so I would like to get it fixed. Yes, I believe you are right. Return an error for all errors. No - nfs_vinvalbuf() returns zero or EINTR, there are no other errors. Does vinvalbuf() return an error from fsync here thats gets missed because vinvalbuf() loops until it returns zero? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: NFS over-quota not detected if utimes() called before fsync()/close()
In article 20130730211200.gd96...@trav.math.uni-bonn.de, Edgar Fuß e...@math.uni-bonn.de wrote: I think the problem is in nfs_setattr(), sys/nfs/nfs_vnops.c:681, where files are flushed before setattr because a later write of cached data might change timestamps or reset sugid bits, but the only return value of nfs_vinvalbuf() that's treated as an error is EINTR. Why? Any comments on this? We are losing mail because of this problem so I would like to get it fixed. Yes, I believe you are right. Return an error for all errors. christos
Re: NFS over-quota not detected if utimes() called before fsync()/close()
Yes, I believe you are right. Return an error for all errors. Any idea what the intent of only catching EINTR was?
Re: NFS over-quota not detected if utimes() called before fsync()/close()
I think the problem is in nfs_setattr(), sys/nfs/nfs_vnops.c:681, where files are flushed before setattr because a later write of cached data might change timestamps or reset sugid bits, but the only return value of nfs_vinvalbuf() that's treated as an error is EINTR. Why? Any comments on this? We are losing mail because of this problem so I would like to get it fixed.
Re: NFS over-quota not detected if utimes() called before fsync()/close()
On Fri, Jun 28, 2013 at 02:44:46PM +0200, Edgar Fu? wrote: On an NFS-mounted file system, when you try to write to a file and are over-quota, the write() succeeds, but a following fsync() or close() fails. However, when you insert a utimes() or futimes() call after the write(), the fsync() or close() succeed and you end up with a zero-length file. [...] Shall I file a PR? ugh! Yes please... -- David A. Holland dholl...@netbsd.org
