From owner-freebsd-stable@FreeBSD.ORG Mon Nov 27 17:05:13 2006 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D20C16A492 for ; Mon, 27 Nov 2006 17:05:13 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E826543D49 for ; Mon, 27 Nov 2006 17:04:10 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (hkjofy@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id kARH51qS045399; Mon, 27 Nov 2006 18:05:06 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id kARH507m045367; Mon, 27 Nov 2006 18:05:00 +0100 (CET) (envelope-from olli) Date: Mon, 27 Nov 2006 18:05:00 +0100 (CET) Message-Id: <200611271705.kARH507m045367@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, rcoleman@criticalmagic.com, security@jim-liesl.org In-Reply-To: <456B1096.3000702@criticalmagic.com> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 27 Nov 2006 18:05:06 +0100 (CET) Cc: Subject: Re: Large msdosfs disk will not mount on RELENG_6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG, rcoleman@criticalmagic.com, security@jim-liesl.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2006 17:05:13 -0000 Richard Coleman wrote: > Oliver Fromme wrote: > > [...] > > However, if the size of the file system exceeds 128 MB That should be 128 GB, of course. > [...] > Because of the potential panics that were mention, I can understand a > reluctance to change the default. But I suspect that (attempting to) > mount a large msdosfs disk is a much more common occurrence than using a > smaller msdosfs disk over NFS. Well, the mentioned problems (running out of kernel memory and NFS export difficulties) can occur with msdosfs file systems of any size, including ones that are smaller than 128 GB. It would be really annoying to not be able to mount a USB stick with a lot of files on a machine with small RAM (it could panic the machine without warning). On the other hand, the default (no MSDOSFS_LARGE) is safe for any number of files, i.e. you cannot panic the system, but you're limited to 128 GB file system size. (Well, you _can_ cause a panic with certain broken file systems, but that's a different story.) It's really chosing the lesser of two evils, but which one is the lesser? The answer depends on whom you ask. :-) I think the best solution would be to convert the kernel option into a mount option, so you can select your evil at mount time without having to recompile and reboot. Then you would even be able to mount your USB stick with the first hack and -- at the same time -- mount your external big disk with the second hack. Someone would have to code that, of course. I'm afraid I'm not volunteering (lack of time). It shouldn't be fairly easy to code, though: just add a flag to the mount (similar to the existing flag for win95 long file names) that indicates which hack to use, and select the apropriate hack at runtime, basically replacing the current #ifdef with an ordinary if(...). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing.