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>