From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 15:07:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B94EB1065670 for ; Sat, 3 Apr 2010 15:07:38 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay006.isp.belgacom.be (mailrelay006.isp.belgacom.be [195.238.6.172]) by mx1.freebsd.org (Postfix) with ESMTP id 55E768FC14 for ; Sat, 3 Apr 2010 15:07:37 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQGAOv2tkvZiCNZ/2dsb2JhbACDEYxCi3dypiCPPIErgm5uBA Received: from 89.35-136-217.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([217.136.35.89]) by relay.skynet.be with ESMTP; 03 Apr 2010 17:07:36 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.3/8.14.3) with ESMTP id o33F7Zdl004149; Sat, 3 Apr 2010 17:07:35 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-current@freebsd.org Date: Sat, 3 Apr 2010 17:07:33 +0200 User-Agent: KMail/1.9.10 References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <4BB644CA.4000807@freebsd.org> <4BB64615.9060601@freebsd.org> In-Reply-To: <4BB64615.9060601@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201004031707.34650.tijl@coosemans.org> Cc: Kostik Belousov , Bruce Evans , Andriy Gapon Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 15:07:38 -0000 On Friday 02 April 2010 21:31:33 Andriy Gapon wrote: > on 02/04/2010 22:26 Andriy Gapon said the following: >> OK, I did it again. >> I tested the below patch using the scenario described above. >> Could you please review and/or test this patch? >> If you like it and it works, I can commit it. >> Thanks! >> >> --- a/sbin/newfs_msdos/newfs_msdos.c >> +++ b/sbin/newfs_msdos/newfs_msdos.c >> @@ -427,6 +427,9 @@ main(int argc, char *argv[]) >> if (bpb.bpbBytesPerSec < MINBPS) >> errx(1, "bytes/sector (%u) is too small; minimum is %u", >> bpb.bpbBytesPerSec, MINBPS); >> + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); >> + if (bpb.bpbSecPerClust == 0) >> + bpb.bpbSecPerClust = 1; >> if (!(fat = opt_F)) { >> if (opt_f) >> fat = 12; >> > > And here is a safer one (in case of a huge sector size > 32KB). > I will appreciate any testing with real media that you might have. > > diff --git a/sbin/newfs_msdos/newfs_msdos.c b/sbin/newfs_msdos/newfs_msdos.c > index 955c3a5..3f2778d 100644 > --- a/sbin/newfs_msdos/newfs_msdos.c > +++ b/sbin/newfs_msdos/newfs_msdos.c > @@ -427,6 +427,12 @@ main(int argc, char *argv[]) > if (bpb.bpbBytesPerSec < MINBPS) > errx(1, "bytes/sector (%u) is too small; minimum is %u", > bpb.bpbBytesPerSec, MINBPS); > + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); > + if (bpb.bpbSecPerClust == 0) > + bpb.bpbSecPerClust = 1; > + if (bpb.bpbSecPerClust * bpb.bpbBytesPerSec > 32 * 1024) > + errx(1, "bytes per sector (%u) is greater than 32k", > + bpb.bpbSecPerClust * bpb.bpbBytesPerSec); > if (!(fat = opt_F)) { > if (opt_f) > fat = 12; Wikipedia's article on FAT has this to say about the maximum size of clusters: "The limit on partition size was dictated by the 8-bit signed count of sectors per cluster, which had a maximum power-of-two value of 64. With the standard hard disk sector size of 512 bytes, this gives a maximum of 32 KB clusters, thereby fixing the "definitive" limit for the FAT16 partition size at 2 gigabytes. On magneto-optical media, which can have 1 or 2 KB sectors instead of 1/2 KB, this size limit is proportionally larger. Much later, Windows NT increased the maximum cluster size to 64 KB by considering the sectors-per-cluster count as unsigned. However, the resulting format was not compatible with any other FAT implementation of the time, and it generated greater internal fragmentation. Windows 98 also supported reading and writing this variant, but its disk utilities did not work with it." I'm not sure the second paragraph is worth supporting, but the first seems to say that 32k limit you have in your patch only applies to disks with 512 byte sectors. For disks with larger sectors it would be proportionally larger.