Date: Fri, 08 Jan 2016 17:10:36 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-amd64@FreeBSD.org Subject: [Bug 205932] [panic] Kernel panic when copying from ext2fs partition to UFS partition Message-ID: <bug-205932-6-B4l5yWH6Jh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-205932-6@https.bugs.freebsd.org/bugzilla/> References: <bug-205932-6@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205932 --- Comment #6 from Damjan Jovanovic <damjan.jov@gmail.com> --- (In reply to Will B from comment #5) In the "cp" tool, function copy_file() in file /usr/src/bin/cp/utils.c has 2 ways of copying a file: mmap + write, and read + write. mmap + write is used only when all of the following are true: * VM_AND_BUFFER_CACHE_SYNCHRONIZED is defined (it is, in Makefile) * It's a regular file (according to S_ISREG()) * The file's size is > 0 * The file's size is <=3D 8 MiB * Calling mmap() succeeds You say it happens on different files each time. My guess is all of the fil= es that it happens on, are regular non-empty files <=3D 8 MiB in size. There's 2 known bugs where mmap() succeeds but reading the mapped contents = can cause problems: 1. The serious bug 205938 where struct buf leaks from ext4_bmapext(), causi= ng a panic on every attempt to read even 1 byte of the mapped data. Because your trace shows the panic happens with lbn=3D0 (the very first block of the fil= e) this is probably the problem here. This bug was fixed in CURRENT yesterday, which is newer than your 10.2-RELEASE. You could try the patch from that bu= g, it does apply and work for me (for a different mmap problem) on 10.2-RELEAS= E. 2. Even with that bug fixed, sparse blocks will at best contain garbage data read from the wrong disk blocks instead of zeroes, corrupting the copied fi= le you create (maybe a panic is also possible?). This is bug 205816 which I previously mentioned. This isn't even fixed in CURRENT, but there is a patc= h on that bug you can try. (BTW you could also use ext4fuse from ports instead of the in-kernel ext2fs driver since it doesn't suffer from problem 1, but it does suffer from prob= lem 2, and I don't know/have a patch for it) With both those patches, copying files from EXT4 should be reliable and correct, but very slow in the mmap + write case (about 250 kB/second with 1= 00% CPU usage) which is unbearably slow if you have lots of files <=3D 8 MiB. I= have a 1 line patch to speed it up about 100-fold, but it only works on CURRENT - 10.2 panics with it. Will keep trying. This is the sad state of current EXT4 support outside Linux... --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-205932-6-B4l5yWH6Jh>