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