Date: Tue, 30 Jul 2002 03:00:09 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/41145: newfs core dump (args : -b 262144 -f 32768) Message-ID: <200207301000.g6UA09hg031789@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/41145; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Ying-Chieh Liao <ijliao@csie.nctu.edu.tw> Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: bin/41145: newfs core dump (args : -b 262144 -f 32768) Date: Tue, 30 Jul 2002 19:59:22 +1000 (EST) On Tue, 30 Jul 2002, Ying-Chieh Liao wrote: > >Description: > > We have a new RAID (SCSI-to-IDE, Maxtor 80G x 8, RAID5) on da1 > when I run newfs with "-b 262144 -f 32768 -m 0", it core-dumped > but it's ok with "-b 65536 -f 8192 -m 0" > > it is strange that I've run newfs -b 262144 on a vinum (80G x 3, RAID1) > and everything is ok There is a kernel limit of MAXBSIZE = 65536, so ufs filesystems with a block size larger than 65536 cannot be mounted in FreeBSD. newfs and fsck_ffs use the same limit, so the cannot create or check such filesystems. newfs tends to die trying since it doesn't check for the limit being exceeded and uses data structures that depend on it not being exceeded. fsck_ffs tends to just not recognise such filesystems, since it checks the limit as part of its sanity check/search for the superblock. Bruce 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?200207301000.g6UA09hg031789>