Jan Stary schreef op zo 30-12-2012 om 12:24 [+0100]: > On Dec 30 10:43:00, m.vandu...@jonker.nl wrote: > > I'm migrating my data from an ext3 partition (formatted under Debian > > 6.0, sparc64) to my new i386 OBSD system. > > You need to give more detail. You installed an i386 obsd machine, > and did what? Took an ext3fs disk out of a Debian sparc64 machine, > put it in the new obsd machine? How did you mount it? > How exactly are you "migrating" it? >
That is correct. And I mounted it mount_ext2fs /dev/wd0i /mnt. The migration was just a simple cp command, but like I said, it even fails a "simple" md5 command. > > When copying I found out that some files weren't copied correctly and > > returned the error: "read error: Invalid argument". > > *Some* files. Other files copied correctly? > Can you tell a pattern of which was which? I haven't found any pattern in the files which fail and which succeed. There are no special characters in the file-names and the files can be successfully accessed via an FFS partition once copied. And the content of a file should never be an issue when trying to retrieve data. > > > The files are usable when mounting the disk under i386 Debian, so it's > > not an cpu-architectural problem. > > So, you put the same sparc64 disk into an i386 Debian machine, > and did what exactly? Copied the whole thing over, with cp, > without a read error? I booted the same i386 machine with a debian live-disk and I could access the disk without any problems. After that I placed the disk back in my sparc64 box and configured NFS to transfer the data to my OBSD system. > > > Other programs trying to operate on these files via ext2fs also fail > > with the same notion, (e.g. md5). And extracting these files from a > > tarball also result in the same error. > > What tarball? I also tried placing the "corrupted" files in a tarball under Debian to see if it could have anything to do with file-names or whatever, but once the "corrupted" files were reached it gave me the same read error. (this was also done on the ext3 fs) > > > The ls command does succeed and shows the correct information > > (file-size, access-time, etc). > > > > When moving these files over via nfs the problem doesn't occur and the > > files are saved correctly on my ffs partition. > > That (or scp) is how I always copied files > from one FS/OS/arch to a completely different FS/OS/arch. > And my point isn't the migration of my data. There is a work-around so I already fixed that. My point is that there apparently is a bug in the ext2fs driver and I want to locate the source of the problem, but I don't know how (yet). I kept my old disk still available for debugging purposes, but I will want to format it to ffs someday in the future. So I want to look into this as soon as possible.