From owner-freebsd-fs Mon Jun 9 17:28:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA23949 for fs-outgoing; Mon, 9 Jun 1997 17:28:19 -0700 (PDT) Received: from tandem.milestonerdl.com (main.milestonerdl.com [204.107.138.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA23925; Mon, 9 Jun 1997 17:28:14 -0700 (PDT) Received: (from marc@localhost) by tandem.milestonerdl.com (8.8.4/8.8.4) id TAA03058; Mon, 9 Jun 1997 19:34:19 GMT Date: Mon, 9 Jun 1997 19:34:18 +0000 () From: Marc Rassbach To: freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Subject: Jaz media and 2.2.2-RELEASE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am not having luck making a /dev/sd1a partition on a jaz disk. The FAQ for zip and jaz from the freebsd site does make a jaz disk via the auto feature of disklabel. An older FAQ on making Jaz disks does work under 2.1.6 but not 2.2.1/2.2.2. I'm looking for pointers here....below is some data from my previous attempts. (I'm not actively reading the lists...can you e-mail replies and I'll summerize back to list) >From a FAQ on Jaz's and how to make them. jaz1gb|Iomega Jaz 1GB - FreeBSD: \ :ty=removable:dt=SCSI:se#512:nt#64:ns#32:nc#1021:rm#5394:\ :pa#2090976:oa#0:ba#4096:fa#1024:ta=4.2BSD: \ :pc#2090976:oc#0: If you go to the Iomega site and look up the solaris-jaz connectivity Iomega recommends a configuration like this.... disklabel -r # /dev/rsd1c: type: SCSI disk: jz1gb label: flags: removeable bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 1018 sectors/unit: 2084864 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 3 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2084864 0 4.2BSD 1024 4096 0 # (Cyl. 0 - 1017) c: 2084864 0 unused 0 0 # (Cyl. 0 - 1017) disklabel -r from a bootable jaz 2.2.2-RELEASE # /dev/rsd1c: type: SCSI disk: sd0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 130 sectors/unit: 2091050 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1992746 98304 4.2BSD 0 0 0 # (Cyl. 6*- 130*) b: 98304 0 swap # (Cyl. 0 - 6*) c: 2091050 0 unused 0 0 # (Cyl. 0 - 130*) From owner-freebsd-fs Tue Jun 10 22:57:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA03479 for fs-outgoing; Tue, 10 Jun 1997 22:57:19 -0700 (PDT) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA03470 for ; Tue, 10 Jun 1997 22:57:16 -0700 (PDT) Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id WAA05138 for fs@freebsd.org; Tue, 10 Jun 1997 22:57:14 -0700 Date: Tue, 10 Jun 1997 22:57:14 -0700 From: Sean Eric Fagan Message-Id: <199706110557.WAA05138@kithrup.com> To: fs@freebsd.org Subject: file size limits question Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Okay, I decided I had a desire to do some testing with large files. So I decided to see how large of a file I could create. I wrote the program included below; it just uses a binary search to find the largest value at which it can lseek() and then write() a byte. On my 2.2-970212-GAMMA (hey that's not a Y2k compliant name!) system, /tmp is an MFS filesystem; $HOME is a normal, SCSI-disk UFS filesystem. When I run this program and create a file in /tmp, it creates a file that is 34376613888 bytes long. When it creates a file in $HOME, it is 2147483647 bytes long. I am surprised by this difference. Can anyone explain it, or do I have to dive into the device driver code? (I am assuming that the limitation is going to be in the device driver, not the filesystem, given that MFS is essentially UFS...) Thanks... Sean. #include #include #include #include #include #include main(int ac, char **av) { int fd; unsigned long long hi, lo, avg; char *fname; if (ac == 2) { fname = av[1]; } else fname = "/tmp/foobar"; fd = open(fname, O_WRONLY|O_TRUNC|O_CREAT, 0666); if (fd == -1) { fprintf(stderr, "%s: cannot open %s: %s\n", av[0], fname, strerror(errno)); exit(1); } lo = 0; hi = 0xffffffffffffffffLL; /* Really big file */ avg = hi; do { if ((lseek(fd, avg, SEEK_SET) == -1) || (write(fd, fname, 1) == -1)) { printf("offset = %qu -- failed\n", avg); hi = avg; } else { printf("offset = %qu -- success\n", avg); lo = avg; } avg = (lo + hi) / 2; } while ((avg != lo) && (avg != hi)); printf ("avg = %qu\n", avg); close (fd); return(0); } From owner-freebsd-fs Wed Jun 11 01:03:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA08876 for fs-outgoing; Wed, 11 Jun 1997 01:03:19 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA08870 for ; Wed, 11 Jun 1997 01:03:15 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id RAA07387; Wed, 11 Jun 1997 17:58:14 +1000 Date: Wed, 11 Jun 1997 17:58:14 +1000 From: Bruce Evans Message-Id: <199706110758.RAA07387@godzilla.zeta.org.au> To: fs@FreeBSD.ORG, sef@Kithrup.COM Subject: Re: file size limits question Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On my 2.2-970212-GAMMA (hey that's not a Y2k compliant name!) system, /tmp >is an MFS filesystem; $HOME is a normal, SCSI-disk UFS filesystem. > >When I run this program and create a file in /tmp, it creates a file that is >34376613888 bytes long. When it creates a file in $HOME, it is 2147483647 >bytes long. 34... == 32G seems to be normal for ufs file systems with a block size of 8K. There seems to be an off by one error in ufs_getlbns(), so triply indirect blocks are never actually allocated (i == 0 corresponds to NIADDR = 3 levels of indirection, and EFBIG is returned when i == 0). Thus the maximum file size is limited mainly by the number of doubly indirect blocks == (block_size/4)^2 == 4M, to block_size^3 / 16. block_size == 8K gives the magic 32G. I once created a 1TB sparse file to test newfs and fsck on. I must have used a large block size to get there, since the bug has been present in all versions of FreeBSD-2.x. Version 1.1 of ufs_bmap.c even has an off by one bug in the array dimension for nindir[]. 2G must be caused by a bug somewhere else. A block size of 4K would give a doubly-indirect-block-limited limit of 4GB. Perhaps there is also a sign extension bug. When I ran the program on a (blocksize = 4K) ext2fs file system, it gave a size of 4402G. This is interesting, since the file size is stored in 32 bits in the disk inode :-). Unmounting and remounting the file system reduced the size to 4243456 bytes. >I am surprised by this difference. Can anyone explain it, or do I have to >dive into the device driver code? (I am assuming that the limitation is >going to be in the device driver, not the filesystem, given that MFS is >essentially UFS...) No, bugs are relatively unlikely in device drivers since they work mostly with 31-bit block numbers and rarely see huge offsets. Bruce From owner-freebsd-fs Wed Jun 11 10:43:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA06551 for fs-outgoing; Wed, 11 Jun 1997 10:43:47 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA06546 for ; Wed, 11 Jun 1997 10:43:45 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA06274; Wed, 11 Jun 1997 10:37:00 -0700 From: Terry Lambert Message-Id: <199706111737.KAA06274@phaeton.artisoft.com> Subject: Re: file size limits question To: sef@Kithrup.COM (Sean Eric Fagan) Date: Wed, 11 Jun 1997 10:37:00 -0700 (MST) Cc: fs@FreeBSD.ORG In-Reply-To: <199706110557.WAA05138@kithrup.com> from "Sean Eric Fagan" at Jun 10, 97 10:57:14 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On my 2.2-970212-GAMMA (hey that's not a Y2k compliant name!) system, /tmp > is an MFS filesystem; $HOME is a normal, SCSI-disk UFS filesystem. > > When I run this program and create a file in /tmp, it creates a file that is > 34376613888 bytes long. When it creates a file in $HOME, it is 2147483647 > bytes long. > > I am surprised by this difference. Can anyone explain it, or do I have to > dive into the device driver code? (I am assuming that the limitation is > going to be in the device driver, not the filesystem, given that MFS is > essentially UFS...) I'm not surprised. But then, I've complained about similar limits in the past in regard to device/offset vs. vnode/offset mapping. CRYPTIC ANSWER 34376613888 bytes = 67141824 blocks = pow( 2, 26) 2147483647 bytes = 4194304 blocks = pow( 2, 22) pow( 2, 26 - 22) = 16 16 * blocksize = 16 * 512 = 8k Hmmm... you seem to be running with an 8k block size on your UFS. CLEAR(ER) ANSWER UFS block counts are in terms of file system blocks MFS block counts are in terms of device driver blocks FreeBSD is limited because of the way it deals with address space mappings for VM objects. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.