Bug 787509

Summary:	Slow client response if log partition is full
Product:	[Community] GlusterFS	Reporter:	Joe Julian <joe>
Component:	logging	Assignee:	Raghavendra Bhat <rabhat>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.1.7	CC:	bugs, gluster-bugs
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-14 19:40:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Joe Julian 2012-02-05 21:03:40 UTC

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.

Comment 1 Amar Tumballi 2012-05-02 19:25:27 UTC

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.

Comment 2 Niels de Vos 2014-11-27 14:54:55 UTC

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.