Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Nov 1996 21:14:02 -0500 (EST)
From:      "John S. Dyson" <toor@dyson.iquest.net>
To:        ache@nagual.ru (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=)
Cc:        toor@dyson.iquest.net, current@freebsd.org, dyson@freebsd.org
Subject:   Re: MSDOS lkm just broken (MAXBSIZE)
Message-ID:  <199611300214.VAA09459@dyson.iquest.net>
In-Reply-To: <199611292051.XAA00689@nagual.ru> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Nov 29, 96 11:51:56 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > > 
> > > panic: getblk: size(32768) > MAXBSIZE(16384)
> > > 
> > Excellent!!! Another disk (filesystem) saved...  This is only
> > panicing under a very very evil situation.  It was never
> > checked before.
> 
> Nothing saved, it simple not work and really work before!
> No evil situation occurse, it was just usual boot stage mount as before.
> 
> It not work by very simple reason: MSDOS lkm awaits MAXBSIZE
> as 32768 and compiled kernel define it as 16384 instead of 32768
> because MSDOSFS NOT defined by kernel because I don't want MSDOSFS
> inside kernel and want is as lkm instead.
>
THE SYSTEM NEVER SUPPORTED 32K out of the BOX!!!  MSDOS WAS ASKING
FOR THE IMPOSSIBLE!!!

> 
> I always have my MSDOS filesystem mounted and it work for me
> for years without any data corruption in both filesystems, it not
> work now.
> 
> Now I forced to define MSDOSFS in my kernel config file to
> bypass your checking (and not use MSDOS lkm as result).
> 
Sorry, but unless you were running with MAXBSIZE=32K you were
heading for trouble.  You can remove the check(panic), and get exactly
what you would have before...  A potentially corrupted filesystem.  The
only reason that you have not had a corrupted file system is by
chance...  Sorry again, that is the situation.  I am working on
a real solution, and hackery is NOT in the plan.

John




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611300214.VAA09459>