xfs
[Top] [All Lists]

Re: A possible xfs bug: cp/mv to/from an xfs filesystem

To: J Landman <landman@xxxxxxxxxxxx>
Subject: Re: A possible xfs bug: cp/mv to/from an xfs filesystem
From: Steve Lord <lord@xxxxxxx>
Date: Tue, 26 Jun 2001 10:03:47 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: Message from J Landman <landman@mediaone.net> of "Tue, 26 Jun 2001 07:49:44 EDT." <Pine.LNX.4.32.0106260732390.16449-100000@dsl-squash.corp.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
Please take a look in the system log to see if you got an oops report
to go with this. Also, can you report the compiler version you used,
and did xfs_repair -n report anything?

This is certainly something I have not seen before by the way.

Any chance of building a debug version of cp and running it in gdb?

Thanks

   Steve


> Folks:
> 
>    Let me know if this is not the appropriate forum for this.  I have what
> I will call an annoying problem.  It seems that cp/mv have stopped working
> between xfs and the other file systems.  Here are the basics:
> 
> uname -a : Linux genome.dtw.macsch.com 2.4.5-xfs #2 Thu Jun 21 03:06:30 EDT 2
> 001 i686
> unknown
> 
> (plain 2.4.5 using the xfs patches from last week for 2.4.5)
> 
> file system /work is a RAID 0 /dev/md0 device, striped across two disks on
> one controller.  Other file systems are reiserfs (or some ext2).
> 
> Here is the problem
> 
> (from a reiserfs filesystem)
> 
> [landman@xxxxxxxxxxxxxxxxxxxxx:~]
> 11 >cp XML-Config-0.2.tar.gz /work/
> Segmentation fault (core dumped)
> 
> (whoops)
> 
> [landman@xxxxxxxxxxxxxxxxxxxxx:~]
> 12 >cp XML-Config-0.2.tar.gz xml.tgz
> 
> (ok)
> 
> now cd to /work (the xfs filesystem)
> [landman@xxxxxxxxxxxxxxxxxxxxx:/work]
> 15 >cp installer  i
> Segmentation fault
> 
> so we see that it may be independent of where it starts from (xfs/reiserfs
> to xfs)
> 
> so I ran strace on the file, and this is what I got near the end (after
> the umask)
> 
> umask(0)                                = 02
> lstat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
> stat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
> stat64("installer", {st_mode=S_IFREG|0755, st_size=4332356, ...}) = 0
> stat64("i", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
> open("installer", O_RDONLY|O_LARGEFILE) = 3
> open("i", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4
> fstat64(4, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
> fstat64(3, {st_mode=S_IFREG|0755, st_size=4332356, ...}) = 0
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
> 
> looking at /bin/cp, I see
> 
> [landman@xxxxxxxxxxxxxxxxxxxxx:/work]
> 17 >ldd /bin/cp
>         libc.so.6 => /lib/libc.so.6 (0x40029000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> 
> [landman@xxxxxxxxxxxxxxxxxxxxx:/work]
> 18 >rpm -qf /lib/libc.so.6
> glibc-2.2.2-4mdk
> 
> This is a mandrake 8.0 system.  I used the original Russell Mandrake
> patched kernel until I started to notice this.  I can move files around
> using tar.  Tar uses the same libraries as cp, with the additional librt,
> and libpthread.  This is all being done using the tcsh.  This uses the
> fileutils-4.0.  I downloaded and handcompiled 4.1 of fileutils, and I get
> the same behavior.
> 
> What else should I do?  I just want to make this go away.  File system was
> built using the 1.0 mkfs.  I have run xfs_check and xfs_repair -n on it.
> I can back it up and rebuild the FS if needed.  Let me know what you
> think.
> 
> Joe
> 
> -- 
>  Joe Landman,
>  landman@xxxxxxxxxxxx
>  joe.landman@xxxxxxxxxxxxxxx



<Prev in Thread] Current Thread [Next in Thread>