From owner-freebsd-bugs@FreeBSD.ORG Thu Mar 3 14:00:40 2005 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F43F16A4CE for ; Thu, 3 Mar 2005 14:00:40 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECDB743D3F for ; Thu, 3 Mar 2005 14:00:39 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j23E0dR8080814 for ; Thu, 3 Mar 2005 14:00:39 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j23E0did080813; Thu, 3 Mar 2005 14:00:39 GMT (envelope-from gnats) Date: Thu, 3 Mar 2005 14:00:39 GMT Message-Id: <200503031400.j23E0did080813@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: dmitry@atlantis.dp.ua Subject: [PATCH] Re: kern/73514: mount_ntfs: can't access large file X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dmitry@atlantis.dp.ua List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 14:00:40 -0000 The following reply was made to PR kern/73514; it has been noted by GNATS. From: dmitry@atlantis.dp.ua To: freebsd-gnats-submit@FreeBSD.org, dohzono@hf.rim.or.jp Cc: Subject: [PATCH] Re: kern/73514: mount_ntfs: can't access large file Date: Thu, 3 Mar 2005 15:57:31 +0200 (EET) Hello! I've reviewed ntfs code and found that it isn't 64-bit clean (it uses 32-bit data and 32-bit min()/max() comparisons instead of 64-bit ones). So I've tried to repair it. Look at results at ftp://external.atlantis.dp.ua/FreeBSD/ntfs-64/ntfs-5.01.patch (patch against 5.3-RELEASE and 5-STABLE) or ftp://external.atlantis.dp.ua/FreeBSD/ntfs-64/ntfs-6.01.patch (patch against HEAD). I verified this patch under 5.3-RELEASE - now sequential read of long (4.9Gb and 6Gb) files works correctly: I can play them using mplayer and verify MD5-sum using gmd5sum. However, mmap() doesn't work correctly and even crashes system after my patch. Before patch, the following command: cmp file.avi file.avi 0x100000000 0x100000000 against file on NTFS causes the following diagnostics: Feb 25 20:42:53 homelynx kernel: ntfs_strategy: ntfs_readattr failed Feb 25 20:42:53 homelynx kernel: vnode_pager_getpages: I/O read error Feb 25 20:42:53 homelynx kernel: vm_fault: pager read error, pid 2774 (cmp) With my patch, I'm getting the following panic (hand-transcribed): panic: vnode_pager_getpages: unexpected missing page: firstaddr: -1, foff: 0x080000000, vnp_size: 0x1127ba3e00 I'm asking for the help of people who know mmap()-related stuff well. I can't find this remaining bug myself. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE