misc/131084: xfs destroys itself after copying data

Elmar Stellnberger estellnb at gmail.com
Wed Jan 28 09:10:02 PST 2009


>Number:         131084
>Category:       misc
>Synopsis:       xfs destroys itself after copying data
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 28 17:10:01 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Elmar Stellnberger
>Release:        FreeBSD 7.1
>Organization:
>Environment:
FreeBSD scaleo.studiob 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan  1 14:37:25 UTC 2009     root at logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
>How-To-Repeat:

>Fix:
By the way is there any effort to support ext3? Ext2 partitions corrupt on crashes, xfs seems to be unstable. Besides this ext3 would pose the only way to share a common home partition between Linux, FreeBSD and Windows.

>Release-Note:
>Audit-Trail:
>Unformatted:
 >mkfs.xfs /dev/ad6s7
 >mount -t xfs /dev/ad6s7 tmp
 >cp -a /Users/elm/.thunderbird tmp/
 >ls tmp
 ls: tmp: Input/output error
 >touch /mnt/tmp/hug
 touch: /mnt/tmp/hug: Input/output error
 > umount tmp
 umount: tmp: stat: Input/output error
 umount: tmp: unknown file system
 > mount| grep tmp
 /dev/ad6s7 on /mnt/tmp (xfs, local)
 > umount /dev/ad6s7
 > mount| grep tmp
 > xfs_check /dev/ad6s7
 ERROR: The filesystem has valuable metadata changes in a log which needs to
 be replayed.  Mount the filesystem to replay the log, and unmount it before
 re-running xfs_check.  If you are unable to mount the filesystem, then use
 the xfs_repair -L option to destroy the log and attempt a repair.
 Note that destroying the log may cause corruption -- please attempt a mount
 of the filesystem before doing this.
 > mount -t xfs /dev/ad6s7 tmp
 mount: /dev/ad6s7 : Operation not supported
 


More information about the freebsd-bugs mailing list