artichoke
Verified User
Minor quibble relating to:
http://www.directadmin.com/features.php?id=733
This is listed as a feature, described as:
Checking for errors when writing to disk and updating files atomically via a rename is normal programming practice, so doing this reliably now is a bug fix, not a feature. Otherwise we would have a long list of features, any time we checked for an error.
Automatically buying a new disk when a filesystem gets full -- now that would be a feature.
Rahul
P.S.
The normal method for checking for output errors is to look at the return value from fclose(). This will return any error reported by the underlying close() system call, which allocates sufficient disk space before returning, even if the cache is not flushed until later. If a hardware error has occurred, the output write count and/or output file size may be correct but the data written to the file might be wrong. In such cases the return value from fclose() is likely to be a better indicator of the output error. I'm sure the DirectAdmin developers have some good reason for counting output file size instead -- maybe they encountered an NFS client that did not properly return an error from close() on an NFS-mounted filesystem. It's still a bug fix, though, not a feature.
http://www.directadmin.com/features.php?id=733
This is listed as a feature, described as:
Checking for errors when writing to disk and updating files atomically via a rename is normal programming practice, so doing this reliably now is a bug fix, not a feature. Otherwise we would have a long list of features, any time we checked for an error.
Automatically buying a new disk when a filesystem gets full -- now that would be a feature.
Rahul
P.S.
The normal method for checking for output errors is to look at the return value from fclose(). This will return any error reported by the underlying close() system call, which allocates sufficient disk space before returning, even if the cache is not flushed until later. If a hardware error has occurred, the output write count and/or output file size may be correct but the data written to the file might be wrong. In such cases the return value from fclose() is likely to be a better indicator of the output error. I'm sure the DirectAdmin developers have some good reason for counting output file size instead -- maybe they encountered an NFS client that did not properly return an error from close() on an NFS-mounted filesystem. It's still a bug fix, though, not a feature.