Bug 703956

Summary:	fsck.gfs finds errors on full file system
Product:	Red Hat Enterprise Linux 5	Reporter:	Nate Straz <nstraz>
Component:	gfs-utils	Assignee:	Robert Peterson <rpeterso>
Status:	CLOSED NOTABUG	QA Contact:	Cluster QE <mspqa-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	5.7	CC:	edamato, swhiteho
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-16 08:29:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Nate Straz 2011-05-11 19:08:55 UTC

Description of problem:

After filling up a GFS file system, a fsck.gfs reports that is has converted unused metadata blocks to free data blocks. In turn fsck.gfs returns 1 indicating it fixed some errors.

Running the same scenario on GFS2 does not result in work for fsck.gfs2 to do.

SCENARIO - [full_filesystem]
Fill a file system and check it
Creating 1G LV full on dash-02
Creating file system on /dev/fsck/full with options '-p lock_nolock -j 1' on dash-02
Device: /dev/fsck/full
Blocksize: 4096
Filesystem Size: 229332
Journals: 1
Resource Groups: 8
Locking Protocol: lock_nolock
Lock Table:

Syncing...
All Done
Mounting gfs /dev/fsck/full on dash-02 with opts ''
checkit starting with:
CREATE
Num files: 1000000
Random Seed: 26405
Verify XIOR Stream: /tmp/checkit-full.26405
Working dir: /mnt/fsck
ttnvjbfjwdkoqhi: write() error: No space left on device
Unmounting /mnt/fsck on dash-02
Starting fsck.gfs of /dev/fsck/full on dash-02
fsck.gfs output in /tmp/gfs_fsck_stress.26405/1.full_filesystem/1.fsck-dash-02.log
fsck.gfs returned 1
fsck.gfs of /dev/fsck/full on dash-02 fixed some errors

[nstraz@try sts-root]$ cat /tmp/gfs_fsck_stress.26405/1.full_filesystem/1.fsck-dash-02.log
Initializing fsck
Clearing journals (this may take a while).
Journals cleared.
Starting pass1
Pass1 complete
Starting pass1b
Pass1b complete
Starting pass1c
Pass1c complete
Starting pass2
Pass2 complete
Starting pass3
Pass3 complete
Starting pass4
Pass4 complete
Starting pass5
Converting 50 unused metadata blocks to free data blocks...
Converting 11 unused metadata blocks to free data blocks...
Converting 12 unused metadata blocks to free data blocks...
Converting 10 unused metadata blocks to free data blocks...
Converting 18 unused metadata blocks to free data blocks...
Converting 28 unused metadata blocks to free data blocks...
Converting 8 unused metadata blocks to free data blocks...
Converting 15 unused metadata blocks to free data blocks...
Pass5 complete
Writing changes to disk

Version-Release number of selected component (if applicable):
gfs-utils-0.1.20-10.el5
kernel-2.6.18-256.el5

How reproducible:
100%

Steps to Reproduce:
1. fill a GFS file system
2. umount and run fsck.gfs
3.

Actual results:
fsck.gfs converts unused metadata blocks to free data blocks and returns that it fixed some errors.

Expected results:
fsck.gfs should not find any errors

Additional info:

Comment 1 Steve Whitehouse 2011-05-12 10:51:59 UTC

The results don't look like an error as such. I assume that the workload will have at some point during its run actually unlinked/rmdired some data? Unless you created a new fs and never deallocated anything, then you are likely to see messages like that.

The messages indicate that some metadata has been converted back for general use in the filesystem. This is not normally done during filesystem operation since, due to a limitation in GFS's journaling system, once a block has been used for metadata, it cannot be converted back to be used for data except via fsck or via the special tool for reclaiming such blocks.

This is one of the issues which was resolved when GFS2 was being written, so it only applied to GFS.

Let me know if I'm missing something, but I don't think this is a real bug.