From owner-freebsd-fs Sun Jul 21 0:15: 1 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C03E37B400; Sun, 21 Jul 2002 00:14:42 -0700 (PDT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (dclient217-162-144-23.hispeed.ch [217.162.144.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF5C43E42; Sun, 21 Jul 2002 00:14:39 -0700 (PDT) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: from beerswilling.netscum.dyndns.dk (ipv6.NetScum.dyndns.dk [2002:d9a2:9017:0:200:c0ff:fefc:19aa]) by dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NetScum.dyndns.dk (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id g6L7EYS00480 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Sun, 21 Jul 2002 09:14:37 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Received: (from root@localhost) by beerswilling.netscum.dyndns.dk (8.11.6/SMI-4.1-R00T0WNED) id g6L7EYi00479; Sun, 21 Jul 2002 09:14:34 +0200 (CEST) (envelope-from bounce@dcf77-zeit.netscum.dyndns.dk) Date: Sun, 21 Jul 2002 09:14:34 +0200 (CEST) Message-Id: <200207210714.g6L7EYi00479@beerswilling.netscum.dyndns.dk> From: BOUWSMA Beery Organization: Men not wearing any pants that dont shave To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: UFS2 panic (and other issues) at mount with unusual `newfs' values X-Hacked: via telnet to your port 25, what else? X-Internet-Access-Provided-By: CABAL MODEM (all hail CABAL) X-NetScum: Yes X-One-And-Only-Real-True-Fluffy: No Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [IPv6-only address above; strip the obvious for IPv4-only mail] [sent to both -current and the -fs list, for no particular reason] Howdy, -current as of about a day ago. Decided to make a monster UFS2 disk to see if it works. It seems that any -f fsize value larger than 8192 given to `newfs' creates a UFS2 filesystem that causes a panic when mounted, even read-only. This appears true for `-b 16384 -f 16384', `-b 32768 -f 16384', and `-b 65536' with both -f 16384 and 32768. Using a value of 8192 for -f with 65536 and 32768 for -b seems in most cases to create a filesystem I can use, regardless of what other parameters I give, so the mount-time panic can be readily repeated. First of all, `newfs' normally coredumps as I observed earlier when a too-large blocksize is given. As the case for a too-small blocksize and fragment size is detected and twiddled in mkfs.c now, I suggest that the same be done for too large, rather than dumping core. The following patch to src/sbin/newfs/mkfs.c can do this: --- mkfs.c-ORIG Fri Jul 19 18:58:40 2002 +++ mkfs.c Sun Jul 21 00:00:44 2002 @@ -196,10 +196,15 @@ if (sblock.fs_bsize < MINBSIZE) { printf("increasing block size from %d to minimum (%d)\n", sblock.fs_bsize, MINBSIZE); sblock.fs_bsize = MINBSIZE; } + if (sblock.fs_bsize > MAXBSIZE) { + printf("decreasing block size from %d to maximum (%d)\n", + sblock.fs_bsize, MAXBSIZE); + sblock.fs_bsize = MAXBSIZE; + } if (sblock.fs_bsize < sblock.fs_fsize) { printf("increasing block size from %d to fragment size (%d)\n", sblock.fs_bsize, sblock.fs_fsize); However, there's a problem, in that bsize, from which sblock.fs_bsize is obtained, has already been used to set a number of other values in newfs.c. So it's probably better to do the check at the time the value is supplied, by this patch to newfs/newfs.c: --- newfs.c-ORIG Fri Jun 21 23:24:53 2002 +++ newfs.c Sun Jul 21 07:12:49 2002 @@ -186,7 +186,8 @@ optarg); break; case 'b': - if ((bsize = atoi(optarg)) < MINBSIZE) + if ((bsize = atoi(optarg)) < MINBSIZE || + bsize > MAXBSIZE) errx(1, "%s: bad block size", optarg); break; case 'c': This, unfortunately, doesn't give a clue as to what the minimum and maximum permissible values are, but I didn't see a simple way of doing this without recomputing all the values (like maxcontig) that depend on bsize, after adjusting it. And speaking of which, since the value for sblock.fs_bsize can be adjusted (theoretically, in what used to be exit() statements long ago), I'm wondering how right it is that the uncorrected bsize gets used before correction to calculate other values. Hmmm. You'll see a result of this in the example I give below (for maxcontig) Still, it's possible to create a new filesystem without real problems, that panics upon mount (even read-only), using values that are theoretically within range, such as the following first commandline I used: /usr/local/obj/5.0-CURRENT/usr/src/sbin/newfs/newfs -U -N -O 2 -i 1549357135 -b 131072 -f 32768 -g 134217728 -h 128 -m 0 -o space /dev/ad2s1e Superficially, the new filesystem looked fine... decreasing block size from 131072 to maximum (65536) ^^^ [my first, but improper, hack] Maxcontig raised to 131072 ^^^ [should not happen, because of my improper hack] density reduced from 1549357135 to 44585039 /dev/ad2s1e: 156334.5MB (320172992 sectors) block size 65536, fragment size 32768 using 15 cylinder groups of 10881.06MB, 174097 blks, 512 inodes. with soft updates super-block backups (for fsck -b #) at: 256, 22284672, 44569088, 66853504, 89137920, 111422336, 133706752, 155991168, 178275584, 200560000, 222844416, 245128832, 267413248, 289697664, 311982080 [00:51:10]root@dastardly.newsbastards.org:~{520}# tunefs -p /dev/ad2s1e tunefs: soft updates: (-n) enabled tunefs: maximum contiguous block count: (-a) 2 tunefs: maximum blocks per file in a cylinder group: (-e) 16384 tunefs: average file size: (-f) 134217728 tunefs: average number of files in a directory: (-s) 128 tunefs: minimum percentage of free space: (-m) 0% tunefs: optimization preference: (-o) space # size offset fstype [fsize bsize bps/cpg] c: 320172993 0 unused 0 0 # (Cyl. 0 - 317631*) e: 320172993 0 4.2BSD 32768 65536 20514 # (Cyl. 0 - 317631*) But as soon as I attempt to mount the filesystem, read-only, *POW* instant panic. Details: panic: bwrite: buffer is not busy??? panic messages: --- panic: vm_fault: fault on nofault entry, addr: c2f9a000 syncing disks... panic: bwrite: buffer is not busy??? Uptime: 46m16s pfs_vncache_unload(): 1 entries remaining Dumping 72 MB #2 0xc01ec2e5 in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #3 0xc022003f in bwrite (bp=0xc2a872c8) at /usr/src/sys/kern/vfs_bio.c:797 #4 0xc0221391 in vfs_bio_awrite (bp=0xc2a872c8) at /usr/src/sys/kern/vfs_bio.c:1637 #5 0xc01c725c in spec_fsync (ap=0xc6dd474c) at /usr/src/sys/fs/specfs/spec_vnops.c:403 #6 0xc01c6e4b in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:121 #7 0xc0299279 in ffs_sync (mp=0xc0a65600, waitfor=2, cred=0xc0a55e80, td=0xc0365a80) at vnode_if.h:463 #8 0xc022f0d0 in sync (td=0xc0365a80, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:127 #9 0xc01ebdc1 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254 #10 0xc01ec2e5 in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #11 0xc02a7b97 in vm_fault (map=0xc0834000, vaddr=3271139328, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:259 #12 0xc02debc5 in trap_pfault (frame=0xc6dd4938, usermode=0, eva=3271139328) at /usr/src/sys/i386/i386/trap.c:747 #13 0xc02de741 in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1050185728, tf_esi = -10238 27968, tf_ebp = -958576032, tf_isp = -958576284, tf_ebx = -1023836160, tf_edx = -1049891840, tf_ecx = 6144, tf_eax = -26357760, tf_trapno = 12, tf_err = 0, tf_e ip = -1070738998, tf_cs = 8, tf_eflags = 66070, tf_esp = -1047358696, tf_ss = 0} ) at /usr/src/sys/i386/i386/trap.c:445 #14 0xc02d16e8 in calltrap () at {standard input}:98 #15 0xc0297772 in ffs_mount (mp=0xc1918400, path=0xc1922180 "/mnt", data=---Can' t read userspace from dump, or kernel process--- ) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:350 #16 0xc0229941 in vfs_mount (td=0xc1565840, fstype=0xc14c8ad0 "ufs", fspath=0xc1922180 "/mnt", fsflags=1, fsdata=0xbfbff090) at /usr/src/sys/kern/vfs_mount.c:944 #17 0xc0229156 in mount (td=0xc1565840, uap=0xc6dd4d14) at /usr/src/sys/kern/vfs_mount.c:709 #18 0xc02df199 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134809385, tf_esi = -1077939 888, tf_ebp = -1077939960, tf_isp = -958575244, tf_ebx = 0, tf_edx = 0, tf_ecx = -1077940224, tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134524503, tf_cs = 31, tf_eflags = 582, tf_esp = -1077940164, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1049 #19 0xc02d171d in syscall_with_err_pushed () at {standard input}:128 ---Can't read userspace from dump, or kernel process--- Here's a slightly cleaner dump, with different parameters used when doing the newfs... panic: vm_fault: fault on nofault entry, addr: c308a000 panic messages: --- panic: vm_fault: fault on nofault entry, addr: c308a000 syncing disks... 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1: dev:ad2s1e, flags:20000220, blkno:128, lblkno:128 giving up on 1 buffers Uptime: 32m50s pfs_vncache_unload(): 1 entries remaining Dumping 72 MB #3 0xc02a7b97 in vm_fault (map=0xc0834000, vaddr=3272122368, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:259 #4 0xc02debc5 in trap_pfault (frame=0xc731b938, usermode=0, eva=3272122368) at /usr/src/sys/i386/i386/trap.c:747 #5 0xc02de741 in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1047912448, tf_esi = -10228 44928, tf_ebp = -953042336, tf_isp = -953042588, tf_ebx = -1022853120, tf_edx = -1047557376, tf_ecx = 6144, tf_eax = -25067520, tf_trapno = 12, tf_err = 0, tf_e ip = -1070738998, tf_cs = 8, tf_eflags = 66070, tf_esp = -1048027536, tf_ss = 0} ) at /usr/src/sys/i386/i386/trap.c:445 #6 0xc02d16e8 in calltrap () at {standard input}:98 #7 0xc0297772 in ffs_mount (mp=0xc172a400, path=0xc1662300 "/mnt", data=---Can' t read userspace from dump, or kernel process--- ) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:350 #8 0xc0229941 in vfs_mount (td=0xc16cef00, fstype=0xc14c8920 "ufs", fspath=0xc1662300 "/mnt", fsflags=1, fsdata=0xbfbff070) at /usr/src/sys/kern/vfs_mount.c:944 #9 0xc0229156 in mount (td=0xc16cef00, uap=0xc731bd14) at /usr/src/sys/kern/vfs_mount.c:709 #10 0xc02df199 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134809385, tf_esi = -1077939 920, tf_ebp = -1077939992, tf_isp = -953041548, tf_ebx = 0, tf_edx = 0, tf_ecx = ---Type to continue, or q to quit--- -1077940480, tf_eax = 21, tf_trapno = 12, tf_err = 2, tf_eip = 134524503, tf_cs = 31, tf_eflags = 582, tf_esp = -1077940196, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1049 #11 0xc02d171d in syscall_with_err_pushed () at {standard input}:128 ---Can't read userspace from dump, or kernel process--- (kgdb) Using fsize of 8192 with bsize of 65536 did *not* result in a panic, even with other values like [07:30:05]root@dastardly.newsbastards.org:~{512}# /usr/local/obj/5.0-CURRENT/us r/src/sbin/newfs/newfs -U -O 2 -i 14864463 -b 65536 -f 8192 -g 134217728 -h 12 8 -m 0 -o space /dev/ad2s1e /dev/ad2s1e: 156334.5MB (320172992 sectors) block size 65536, fragment size 8192 using 44 cylinder groups of 3628.00MB, 58048 blks, 256 inodes. with soft updates super-block backups (for fsck -b #) at: 256, 7430400, 14860544, 22290688, 29720832, 37150976, 44581120, 52011264, 59441408, 66871552, 74301696, 81731840, 89161984, 96592128, 104022272, 111452416, 118882560, 126312704, 133742848, 141172992, 148603136, 156033280, 163463424, 170893568, 178323712, 185753856, 193184000, 200614144, 208044288, 215474432, 222904576, 230334720, 237764864, 245195008, 252625152, 260055296, 267485440, 274915584, 282345728, 289775872, 297206016, 304636160, 312066304, 319496448 This one mounted fine, and seems to be about the `best' I can do at the moment. Yeah yeah yeah, I know the fine manpage sez The optimal block:fragment ratio is 8:1. Other ratios are possible, but are not recommended, and may produce poor results. but I've used such values with UFS-not-2 with no real problems. If anyone's wondering about such a thing, when i attempt to mount this disk under -stable (without UFS2), it sees the original old UFS filesystem I had created several days ago on this disk as if the UFS2 filesystem never was created. Whether this might have anything to do with the panics I see, well, I thought I should mention that before doing the -O 2 UFS2 newfs'ing, I had created a normal filesystem, should that mean anything. And obviously, I won't be able to do anything with this UFS2 filesystem under -stable, yet... thanks barry bouwsma To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 12:15:25 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 461C437B400 for ; Mon, 22 Jul 2002 12:15:23 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1878343E65 for ; Mon, 22 Jul 2002 12:15:23 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id EF64AAE272; Mon, 22 Jul 2002 12:15:22 -0700 (PDT) Date: Mon, 22 Jul 2002 12:15:22 -0700 From: Alfred Perlstein To: fs@freebsd.org Subject: rename hardlinks "works" on FreeBSD, but no-op on others Message-ID: <20020722191522.GA77219@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org A coworker recently asked me (slightly modified): ...it says that if you rename file A to file B where A and B are hard links to each other, it does nothing. I thought this was kind of odd so I tried the experiment on Linux and sure enough it does the same there: no error and both A and B still exist after the rename. I tried the same experiment on Solaris 8 and got the same effect. I tried the same experiment on FreeBSD and it did the obviously correct thing and removed the old name. What gives? It seems that we do the right thing, however: 1) are we standards compliant? 2) just for curiousity, why would others silently fail? thanks, -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 12:28:45 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDCD137B400 for ; Mon, 22 Jul 2002 12:28:42 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 6214A43E67 for ; Mon, 22 Jul 2002 12:28:42 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 71793 invoked from network); 22 Jul 2002 19:28:40 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 22 Jul 2002 19:28:40 -0000 Message-ID: <3D3C5CE8.6090607@tenebras.com> Date: Mon, 22 Jul 2002 12:28:40 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020717 X-Accept-Language: en-us, en, fr-fr, ru MIME-Version: 1.0 To: Alfred Perlstein Cc: fs@freebsd.org Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others References: <20020722191522.GA77219@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Alfred Perlstein wrote: > What gives? > > It seems that we do the right thing, however: > > 1) are we standards compliant? > 2) just for curiousity, why would others silently fail? We aren't compliant with the Single UNIX Specification, which says that mv is equivalent to invoking rename(), and the man page for rename sez If the old argument and the new argument both refer to, and both link to the same existing file, rename() returns successfully and performs no other action. The FreeBSD man page claims POSIX.2 compliance for mv, but I don't recall whether POSIX addresses mv directly. Obviously you'd only have this happen for files on the same filesystem, since rename(2) doesn't work otherwise. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 12:30: 9 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72DCD37B401 for ; Mon, 22 Jul 2002 12:30:07 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 26E7143E31 for ; Mon, 22 Jul 2002 12:30:07 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 71816 invoked from network); 22 Jul 2002 19:30:06 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 22 Jul 2002 19:30:06 -0000 Message-ID: <3D3C5D3D.2010209@tenebras.com> Date: Mon, 22 Jul 2002 12:30:05 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020717 X-Accept-Language: en-us, en, fr-fr, ru MIME-Version: 1.0 To: Michael Sierchio Cc: Alfred Perlstein , fs@freebsd.org Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others References: <20020722191522.GA77219@elvis.mu.org> <3D3C5CE8.6090607@tenebras.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Michael Sierchio wrote: > We aren't compliant with the Single UNIX Specification, which says > that mv is equivalent to invoking rename(), and the man page for > rename sez ^rename^XSH rename^ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 14:41:56 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9150437B400 for ; Mon, 22 Jul 2002 14:41:51 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F69C43E42 for ; Mon, 22 Jul 2002 14:41:51 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 239D0AE27E; Mon, 22 Jul 2002 14:41:51 -0700 (PDT) Date: Mon, 22 Jul 2002 14:41:51 -0700 From: Alfred Perlstein To: Michael Sierchio Cc: fs@freebsd.org Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others Message-ID: <20020722214151.GF77219@elvis.mu.org> References: <20020722191522.GA77219@elvis.mu.org> <3D3C5CE8.6090607@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3C5CE8.6090607@tenebras.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Michael Sierchio [020722 12:30] wrote: > Alfred Perlstein wrote: > > > What gives? > > > >It seems that we do the right thing, however: > > > >1) are we standards compliant? > >2) just for curiousity, why would others silently fail? > > We aren't compliant with the Single UNIX Specification, which says > that mv is equivalent to invoking rename(), and the man page for > rename sez > > If the old argument and the new argument both refer to, and both > link to the same existing file, rename() returns successfully and > performs no other action. > > The FreeBSD man page claims POSIX.2 compliance for mv, but I don't recall > whether POSIX addresses mv directly. > > Obviously you'd only have this happen for files on the same filesystem, > since rename(2) doesn't work otherwise. Wait... calling rename(2) removes the first link if done like this: #include #include #include int main(int argc, char **argv) { int err; err = rename(argv[1], argv[2]); if (err) perror("rename"); return (err == 0 ? EXIT_SUCCESS : EXIT_FAILURE); } ~ % gcc -Wall t.c ~ % ln b a ~ % ls -li a b 3472127 -rw-r--r-- 2 bright bright 0 Jul 22 14:30 a 3472127 -rw-r--r-- 2 bright bright 0 Jul 22 14:30 b ~ % ./a.out a b ~ % ls -li a b ls: a: No such file or directory 3472127 -rw-r--r-- 1 bright bright 0 Jul 22 14:30 b So, do we need to fix rename(2)? Or do we simply need mv(1) to match rename(2)'s semantics? For compliance? Also, NFSv4 requires this stupid behavior: If oldname and newname both refer to the same file (they might be hard links of each other), then RENAME should perform no action and return success. Do we need to fix this? -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 20:51:27 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DB8637B400; Mon, 22 Jul 2002 20:51:23 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B2C743E31; Mon, 22 Jul 2002 20:51:23 -0700 (PDT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17Wqhm-0007e9-00; Mon, 22 Jul 2002 20:51:22 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-stable@freebsd.org, freebsd-fs@freebsd.org Subject: Re: File system failure! URGENT Help needed! References: <20020623114405.A42706@moya.lambermont.dyndns.org> <20020623125321.A90926-100000@digitalfreaks.org> Message-Id: Date: Mon, 22 Jul 2002 20:51:22 -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> If you have a spare drive that is exactly the same type you could make a >> binary copy of the disk to it, and don't need to worry about making the >> prolem worse while recovering the data with inode magic. > On one of the spare disks put the data on with dd, here's two utils that will > help: > /usr/ports/sysutils/ffsrecov > /usr/ports/sysutils/gpart so now this has happened to me. dell laptop c600 f1 win98se f3 freebsd 4.6-stable heavy disk activity causes system power down. disk diags say disk is sick. if i have to replace the drive, i want to o put old drive in second drive slot o build it from first drive o swap but, if heavy disk activity kills the box, then i want a very 'calm' dd. any clues? or, i can build the new freebsd easily. but is there a way to dump/restore the win98se partition from freebsd? randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 21: 2:19 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB20837B400 for ; Mon, 22 Jul 2002 21:02:12 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E4E943E5E for ; Mon, 22 Jul 2002 21:02:11 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA24101; Tue, 23 Jul 2002 14:02:06 +1000 Date: Tue, 23 Jul 2002 14:06:14 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alfred Perlstein Cc: fs@FreeBSD.ORG Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others In-Reply-To: <20020722191522.GA77219@elvis.mu.org> Message-ID: <20020723133856.L28400-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 22 Jul 2002, Alfred Perlstein wrote: > A coworker recently asked me (slightly modified): > > ...it says that if you rename file A to file B where A and B are > hard links to each other, it does nothing. I thought this was > kind of odd so I tried the experiment on Linux and sure enough > it does the same there: no error and both A and B still exist > after the rename. > > I tried the same experiment on Solaris 8 and got the same effect. > > I tried the same experiment on FreeBSD and it did the obviously > correct thing and removed the old name. > > What gives? > > It seems that we do the right thing, however: > > 1) are we standards compliant? No. > 2) just for curiousity, why would others silently fail? Because they are standards compliant (even though the standard may be wrong here). I fixed this in Linux back in 1992 or 1993, and in my version of FreeBSD a few months later, but never got around to committing the fix. I know too much about this because Minix has or had test programs for it, and I ran these tests to find bugs in early versions of Linux, FreeBSD and in the tests themselves. This patch has been tested for 9-10 years :-). It is a bit incomplete -- it doesn't remove the broken code, and filesystems still do extra work to handle the fvp == tvp case. %%% Index: vfs_syscalls.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.268 diff -u -2 -r1.268 vfs_syscalls.c --- vfs_syscalls.c 13 Jul 2002 04:07:12 -0000 1.268 +++ vfs_syscalls.c 13 Jul 2002 20:22:32 -0000 @@ -2519,4 +2516,5 @@ if (fvp == tdvp) error = EINVAL; +#if 0 /* * If source is the same as the destination (that is the @@ -2529,4 +2527,13 @@ fromnd.ni_cnd.cn_namelen)) error = -1; +#else + /* + * If the source is the same as the destination (that is, if they + * are links to the same vnode), then there is nothing to do. + * POSIX standard. + */ + if (fvp == tvp) + error = -1; +#endif out: if (!error) { %%% Here is the ufs code for the fvp == tvp case: % /* % * Check if just deleting a link name or if we've lost a race. % * If another process completes the same rename after we've looked % * up the source and have blocked looking up the target, then the % * source and target inodes may be identical now although the % * names were never linked. % */ % if (fvp == tvp) { % if (fvp->v_type == VDIR) { % /* % * Linked directories are impossible, so we must % * have lost the race. Pretend that the rename % * completed before the lookup. % */ % #ifdef UFS_RENAME_DEBUG % printf("ufs_rename: fvp == tvp for directories\n"); % #endif % error = ENOENT; % goto abortit; % } % % /* Release destination completely. */ % vput(tdvp); % vput(tvp); % % /* % * Delete source. There is another race now that everything % * is unlocked, but this doesn't cause any new complications. % * Relookup() may find a file that is unrelated to the % * original one, or it may fail. Too bad. % */ % vrele(fdvp); % vrele(fvp); % fcnp->cn_flags &= ~MODMASK; % fcnp->cn_flags |= LOCKPARENT | LOCKLEAF; % if ((fcnp->cn_flags & SAVESTART) == 0) % panic("ufs_rename: lost from startdir"); % fcnp->cn_nameiop = DELETE; % VREF(fdvp); % error = relookup(fdvp, &fvp, fcnp); % if (error == 0) % vrele(fdvp); % if (fvp == NULL) { % #ifdef UFS_RENAME_DEBUG % printf("ufs_rename: from name disappeared\n"); % #endif % return (ENOENT); % } % error = VOP_REMOVE(fdvp, fvp, fcnp); % if (fdvp == fvp) % vrele(fdvp); % else % vput(fdvp); % vput(fvp); % return (error); % } I don't understand the race case now, although ISTR fixing it. Races from using relookup() may also need to be considered. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 21:29:20 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 871DD37B400 for ; Mon, 22 Jul 2002 21:29:18 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5267043E4A for ; Mon, 22 Jul 2002 21:29:18 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 1C512AE160; Mon, 22 Jul 2002 21:29:18 -0700 (PDT) Date: Mon, 22 Jul 2002 21:29:18 -0700 From: Alfred Perlstein To: Bruce Evans Cc: fs@FreeBSD.ORG Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others Message-ID: <20020723042918.GI77219@elvis.mu.org> References: <20020722191522.GA77219@elvis.mu.org> <20020723133856.L28400-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020723133856.L28400-100000@gamplex.bde.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bruce Evans [020722 21:04] wrote: > > > > It seems that we do the right thing, however: > > > > 1) are we standards compliant? > > No. > > > 2) just for curiousity, why would others silently fail? > > Because they are standards compliant (even though the standard may be wrong > here). > > I fixed this in Linux back in 1992 or 1993, and in my version of FreeBSD > a few months later, but never got around to committing the fix. Can you commit it now? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 21:32:40 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B187E37B431 for ; Mon, 22 Jul 2002 21:32:30 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6F843E5E for ; Mon, 22 Jul 2002 21:32:29 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id OAA28320; Tue, 23 Jul 2002 14:32:25 +1000 Date: Tue, 23 Jul 2002 14:36:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alfred Perlstein Cc: fs@FreeBSD.ORG Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others In-Reply-To: <20020723133856.L28400-100000@gamplex.bde.org> Message-ID: <20020723141104.G28400-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 23 Jul 2002, Bruce Evans wrote: > On Mon, 22 Jul 2002, Alfred Perlstein wrote: > > > A coworker recently asked me (slightly modified): > > > > ...it says that if you rename file A to file B where A and B are > > hard links to each other, it does nothing. I thought this was > > kind of odd so I tried the experiment on Linux and sure enough > > it does the same there: no error and both A and B still exist > > after the rename. > > > > I tried the same experiment on Solaris 8 and got the same effect. > > > > I tried the same experiment on FreeBSD and it did the obviously > > correct thing and removed the old name. > > > > What gives? > > > > It seems that we do the right thing, however: > > > > 1) are we standards compliant? > > No. > > > 2) just for curiousity, why would others silently fail? > > Because they are standards compliant (even though the standard may be wrong > here). POSIX.1-2001 apparently attemps to fix this. POSIX.1-1996 says: "If the _old_ argument and the _new_ argument both refer to links to the same existing file, the rename() function shall return successfully and perform no other action". I don't see how "same file" in this can be read as applying to directory entries and not inodes. However, the rationale strongly suggests this (it says that the behaviour is supposed to be compatible with undocumented 4.3BSD behaviour, so that rename("x", "x") doesn't remove "x"). POSIX.1-2001-draft7 says: "If the _old_ argument and the _new_ argument resolve to [!!] the same existing file, the rename() function shall return successfully and perform no other action". The standard still uses "refer to [...] file" in other places, so the changed wording is apparently meant to say that sameness is at the level of directory entries (much like the comment in the kernel defines it). Changing "existing file" to "pathname to existing file" would be just wrong, since sameness is not at the level of pathnames, so it is probably wrong to even hint at pathname resolution here. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 22 22:59:56 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C473937B400 for ; Mon, 22 Jul 2002 22:59:53 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8818943E31 for ; Mon, 22 Jul 2002 22:59:53 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 342BDAE165; Mon, 22 Jul 2002 22:59:53 -0700 (PDT) Date: Mon, 22 Jul 2002 22:59:53 -0700 From: Alfred Perlstein To: Bruce Evans Cc: fs@FreeBSD.ORG Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others Message-ID: <20020723055953.GJ77219@elvis.mu.org> References: <20020723133856.L28400-100000@gamplex.bde.org> <20020723141104.G28400-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020723141104.G28400-100000@gamplex.bde.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Bruce Evans [020722 21:32] wrote: > > POSIX.1-2001 apparently attemps to fix this. POSIX.1-1996 says: > > "If the _old_ argument and the _new_ argument both refer to links to the > same existing file, the rename() function shall return successfully and > perform no other action". > > I don't see how "same file" in this can be read as applying to directory > entries and not inodes. However, the rationale strongly suggests this > (it says that the behaviour is supposed to be compatible with undocumented > 4.3BSD behaviour, so that rename("x", "x") doesn't remove "x"). > > POSIX.1-2001-draft7 says: > > "If the _old_ argument and the _new_ argument resolve to [!!] the same > existing file, the rename() function shall return successfully and > perform no other action". > > The standard still uses "refer to [...] file" in other places, so the > changed wording is apparently meant to say that sameness is at the > level of directory entries (much like the comment in the kernel defines > it). Changing "existing file" to "pathname to existing file" would > be just wrong, since sameness is not at the level of pathnames, so it > is probably wrong to even hint at pathname resolution here. Er, ok. Frankly since we're the only ones that do it "wrong" and NFSv4 specifically states: [http://www.ietf.org/rfc/rfc3010.txt - page 153] If oldname and newname both refer to the same file (they might be hard links of each other), then RENAME should perform no action and return success. ...is there some way I can convince you to polish up and commit your deltas? -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jul 24 6:43:22 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04F2137B400 for ; Wed, 24 Jul 2002 06:43:21 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1175443E3B for ; Wed, 24 Jul 2002 06:43:20 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA01409; Wed, 24 Jul 2002 23:43:15 +1000 Date: Wed, 24 Jul 2002 23:47:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alfred Perlstein Cc: fs@FreeBSD.ORG Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others In-Reply-To: <20020723055953.GJ77219@elvis.mu.org> Message-ID: <20020724234432.P33567-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 22 Jul 2002, Alfred Perlstein wrote: > Er, ok. Frankly since we're the only ones that do it "wrong" and > NFSv4 specifically states: > > [http://www.ietf.org/rfc/rfc3010.txt - page 153] > If oldname and newname both refer to the same file (they might be > hard links of each other), then RENAME should perform no action > and return success. > > ...is there some way I can convince you to polish up and commit your > deltas? NFSv4 is fairly convincing. I'll clean up my patch and commit something later this week. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Jul 24 16:14:30 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 954E437B400 for ; Wed, 24 Jul 2002 16:14:28 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4008743E4A for ; Wed, 24 Jul 2002 16:14:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0419.cvx22-bradley.dialup.earthlink.net ([209.179.199.164] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17XVKq-0000dn-00; Wed, 24 Jul 2002 16:14:25 -0700 Message-ID: <3D3F34A1.5BD85141@mindspring.com> Date: Wed, 24 Jul 2002 16:13:37 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Alfred Perlstein , fs@FreeBSD.ORG Subject: Re: rename hardlinks "works" on FreeBSD, but no-op on others References: <20020724234432.P33567-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > NFSv4 is fairly convincing. I'll clean up my patch and commit something > later this week. No, it's not. The *single* most important comment I made on 4 occasions was ignored. Section 2.2: ... An adjunct time maintenance protocol is recommended to reduce client and server time skew. ... 8.12. Clocks and Calculating Lease Expiration ... To avoid the need for synchronized clocks, lease times are granted by the server as a time delta. However, there is a requirement that the client and server clocks do not drift excessively over the duration of the lock. Jackasses. All they had to do was include the localtime on any request whose response could include a timestamp, and then send deltas instead of absolutes over the wire in all responses: LET local time since epoch RET remote time since epoch LFT local file time RFT remote filetime delta = LET - RET + LFT RFT = RET + delta And then all of the time synchronization requirements between nodes totally disappear. The assinine synchronization requirement was *the biggest issue* for NFSv2, remained *the biggest issue* for NFSv3, and they happily carried the albatross on their necks into the future with them, so they didn't have to disturb their "NFSv4 implementations" that they made before the standard was even a gleam in most people's eyes. And don't even get me started on character set normalization... Grrrr. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Jul 25 16:23:42 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 702A637B400 for ; Thu, 25 Jul 2002 16:23:39 -0700 (PDT) Received: from pdq.com (pdq.com [216.29.182.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id D556E43E86 for ; Thu, 25 Jul 2002 16:23:38 -0700 (PDT) (envelope-from pha@pdq.com) Received: from localhost (pha@localhost) by pdq.com (8.11.6/8.11.6) with ESMTP id g6PNNbM29840 for ; Thu, 25 Jul 2002 19:23:38 -0400 (EDT) (envelope-from pha@pdq.com) Date: Thu, 25 Jul 2002 19:23:37 -0400 (EDT) From: "Paul H. Anderson" X-X-Sender: pha@localhost To: freebsd-fs@FreeBSD.ORG Subject: >1TB UFS FS? Message-ID: <20020725191329.B29788-100000@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I just put together a system with 12 120GB drives using an Escalade 7500-12 controller. I installed FreeBSD 4.6 on it. The driver supports this new card very well (thanks to whoever wrote it!). I would like to, if possible, use a larger than 1 TB filesystem (RAID 5 w/10 drives + parity drive + 1 hot spare drive). The FAQ says there is a soft limit at 1TB - and that someone has run 4TB systems with modifications. Can anyone tell me approximately or exactly what those modifications are? I'm comfortable rebuilding kernels, commands and libraries, or the whole thing if I need to. I hacked /usr/src/sbin/newfs/mkfs.c to use unsigned block addresses, which seems to allow correct lseek() calls, but the subsequent write() fails due to invalid argument. Before I dive into the kernel, knowing if other folks have already done this, and what they did would be very helpful. I know that I can split the drives to two RAID 5 setups (5 drives + 1 parity), and get nearly the same thing, which should work with no problems. Thanks for your time and bandwidth, Paul +---------------------------------------------------+ | Paul Anderson Public Data Queries, Inc. | | pha@pdq.com 734-213-4964 x308 | +---------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 26 17:59: 5 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEBEB37B400 for ; Fri, 26 Jul 2002 17:59:04 -0700 (PDT) Received: from host.ourhost.net (host.ourhost.net [209.239.38.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A50943E3B for ; Fri, 26 Jul 2002 17:59:04 -0700 (PDT) (envelope-from euroboy@ourhost.net) Received: (from ourhost@localhost) by host.ourhost.net (8.10.2/8.10.2) id g6R0ws115010; Fri, 26 Jul 2002 20:58:54 -0400 Date: Fri, 26 Jul 2002 20:58:54 -0400 From: euroboy@ourhost.net Message-Id: <200207270058.g6R0ws115010@host.ourhost.net> X-Authentication-Warning: host.ourhost.net: ourhost set sender to euroboy@ourhost.net using -f To: freebsd-fs@FreeBSD.ORG Subject: Re: Inc or its affiliates. References: <200207270056.g6R0umM58911@logs-wa.proxy.aol.com> In-Reply-To: <200207270056.g6R0umM58911@logs-wa.proxy.aol.com> X-Loop: default@ourhost.net Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is an autoresponder. I'll never see your message. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message