Date: Sat, 23 Feb 2002 22:21:20 -0800 (PST) From: Luigi Rizzo <rizzo@icir.org> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/35269: possible panics with 4:1 filesystem ratios Message-ID: <200202240621.g1O6LKq79572@iguana.icir.org>
next in thread | raw e-mail | index | archive | help
>Number: 35269 >Category: kern >Synopsis: possible panics with 4:1 filesystem ratios >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: Sat Feb 23 22:30:01 PST 2002 >Closed-Date: >Last-Modified: >Originator: Luigi Rizzo >Release: FreeBSD 4.5-RELEASE i386 >Organization: >Environment: System: FreeBSD iguana.icir.org 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Mon Feb 4 15:00:58 PST 2002 root@iguana.icir.org:/usr/src/sys/compile/ACIRI-4.5-USB i386 >Description: There are likely problems with filesystems having 4:1 block:frag ratios, possibly leading to panics trying to access unmapped pages. My suspect is that some part of the code assumes a 8:1 ratio, so when givne a fragment size, it tries to access an entire "block" 8 times the size of the fragment. >How-To-Repeat: One way is to try and use an NFS-mounted filesystem with 4k:1k blocks/fragments.(e.g. changing the defaults in mount_md in /etc/rc.diskless{1,2} and using them on a diskless client). If you are lucky, the faulty code will try to access a block of 8-1k fragments, the second part of which will be unmapped and thus result in a panic. I suspect that you won't be able to reproduce the problem with 2k/512 layouts as the 8 fragments will still be within a page. >Fix: source code browsing... >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202240621.g1O6LKq79572>