Description of problem: If the partition to which the log is being written becomes full, the client's response time slows significantly. How reproducible: Always Steps to Reproduce: 1. Mount the client where the partition containing the log file is nearly full. 2. Access the client mount point enough to fill the log partition. Actual results: File and directory access slows to a crawl. Expected results: The client's performance would not be adversely affected.
We internally do 'fprintf(logfile,"%s", msg); fflush(logfile);' while logging a message. It is important to understand the behavior of fprintf();fflush(); when the disk is full to understand the behavior seen with GlusterFS. One of the goal is to make sure we don't do too much logging, so due to GlusterFS's logs the FS is not 100% full, but the issue will persist anyways because the backend FS can be 100% full due to other applications also. Not treating it as a blocker for 3.3.0 release, but a proper fix/solution/work around would be worked on for subsequent minor releases.
The version that this bug has been reported against, does not get any updates from the Gluster Community anymore. Please verify if this report is still valid against a current (3.4, 3.5 or 3.6) release and update the version, or close this bug. If there has been no update before 9 December 2014, this bug will get automatocally closed.