From owner-freebsd-fs Mon Feb 19 15:32:29 2001 Delivered-To: freebsd-fs@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 8625737B6BC for ; Mon, 19 Feb 2001 15:32:22 -0800 (PST) Received: from jacuzzi ([24.200.106.26]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id G912PX03.F8N for ; Mon, 19 Feb 2001 18:32:21 -0500 Received: from cognac (cognac.local.mindstep.com [192.168.10.4]) by jacuzzi (Postfix) with SMTP id 2BD0E3D83 for ; Mon, 19 Feb 2001 18:31:35 -0500 (EST) From: "Patrick Bihan-Faou" To: Subject: Lockups on RELENG_4 with softupdates Date: Mon, 19 Feb 2001 18:33:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am observing frequent lockups on one of our servers. This machine has a fairly recent version of RELENG_4 (last update around january 15, 2001), and is using softupdates on all disks. I don't really know if the lockups are related to softupdates of not, but they seem to happen when there is a lot of activity on the disks (usually large deletes). Anyway, when the machine freezes, it does not even respond to the keyboard. What can I do to find the root of these lockups ? Included are the mount and dmesg outputs. Patrick. root@nitro# mount /dev/ad0s1a on / (ufs, local, noatime, suiddir, soft-updates) /dev/ad1s1e on /music (ufs, local, noatime, read-only, suiddir) /dev/ad3s1e on /music (ufs, local, noatime, union, suiddir, soft-updates) procfs on /proc (procfs, local) root@nitro# dmesg Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-STABLE #0: Wed Feb 14 17:19:31 EST 2001 herve@nitro:/usr/src/sys/compile/NITRO_DDB Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K7(tm) Processor (503.53-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x612 Stepping = 2 Features=0x81f9ff AMD Features=0xc0400000 real memory = 402653184 (393216K bytes) avail memory = 388141056 (379044K bytes) Preloaded elf kernel "kernel" at 0xc0370000. Pentium Pro MTRR support enabled apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 5.0 irq 11 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 chip1: at device 4.4 on pci0 pcm0: port 0xc800-0xc803,0xcc00-0xcc03,0xd000-0xd0ff irq 12 at device 4.5 on pci0 rl0: port 0xc400-0xc4ff mem 0xeffffe00-0xeffffeff irq 9 at device 14.0 on pci0 rl0: Ethernet address: 00:50:ba:b0:9b:8a miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sym0: <810a> port 0xd800-0xd8ff mem 0xefffff00-0xefffffff irq 10 at device 16.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A pca0 at port 0x40 on isa0 sbc0: at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0 pcm1: on sbc0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold lpt0: on ppbus0 lpt0: Interrupt-driven port ad0: 19541MB [39704/16/63] at ata0-master UDMA66 ad1: 12982MB [26377/16/63] at ata0-slave UDMA66 ad3: 29311MB [59554/16/63] at ata1-slave UDMA66 acd0: CDROM at ata1-master using WDMA2 Waiting 2 seconds for SCSI devices to settle sa0 at sym0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 8) Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted cd0 at sym0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 8.333MB/s transfers (8.333MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed module_register: module netgraph already exists! linker_file_sysinit "netgraph.ko" failed to register! 17 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Feb 19 23: 0:56 2001 Delivered-To: freebsd-fs@freebsd.org Received: from milquetoast.cs.mcgill.ca (milquetoast.CS.McGill.CA [132.206.2.5]) by hub.freebsd.org (Postfix) with ESMTP id D993637B4EC for ; Mon, 19 Feb 2001 23:00:53 -0800 (PST) (envelope-from mat@milquetoast.cs.mcgill.ca) Received: (from mat@localhost) by milquetoast.cs.mcgill.ca (8.9.3/8.9.3) id BAA03184; Tue, 20 Feb 2001 01:35:27 -0500 (EST) Date: Tue, 20 Feb 2001 01:35:27 -0500 From: Mathew KANNER To: Patrick Bihan-Faou Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Lockups on RELENG_4 with softupdates Message-ID: <20010220013526.A28589@cs.mcgill.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: Patrick Bihan-Faou's message [Lockups on RELENG_4 with softupdates] as of Mon, Feb 19, 2001 at 06:33:43PM -0500 Organization: I speak for myself, operating in Montreal, CANADA Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Feb 19, Patrick Bihan-Faou wrote: > [...] > Anyway, when the machine freezes, it does not even respond to the keyboard. > What can I do to find the root of these lockups ? Nothing obvious seems wrong to me. I've seem hangs with ata disks that were accelerated by softupdates but its been >9 months since. If you don't hear from anyone else, try the following: -Download a snapshot from releng4.freebsd.org and work with a generic kernel. -Find a trigger that hangs the machine, -Try it with and without softupdates for every disk. Remove the ata-slave disk and repeat. Good luck, --Mat -- Mathew Kanner Sys Admin at large Obtuse quote: He [not me] understands: "This field of perception is void of perception of man." -- The Quintessence of Buddhism To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 20 12:25:29 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.cise.ufl.edu (beach.cise.ufl.edu [128.227.205.211]) by hub.freebsd.org (Postfix) with ESMTP id A552537B401 for ; Tue, 20 Feb 2001 12:25:25 -0800 (PST) (envelope-from jfh@cise.ufl.edu) Received: from cise.ufl.edu (waterspout.cise.ufl.edu [128.227.205.52]) by mail.cise.ufl.edu (Postfix) with ESMTP id 090D5DCC3 for ; Tue, 20 Feb 2001 15:25:24 -0500 (EST) To: freebsd-fs@freebsd.org Subject: Softupdates umount bug? Or vinum problem? X-mailer: nmh-1.0.3/vi Date: Tue, 20 Feb 2001 15:25:24 -0500 From: "James F. Hranicky" Message-Id: <20010220202525.090D5DCC3@mail.cise.ufl.edu> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Over the past few weeks, I've been playing around with a filesystem destined to become our mail filesystem, doing things like turning softupdates on/off, and setting various other fs options. All in all, a lot of mounting/umounting, etc. Three times now, something I've done has caused the filesystem to become corrupt, twice beyond repair. The first two times caused a panic, and the third time, I simply unmounted the filesystem after some IO and ran fsck, and got a badly mangled filesystem. I'm wondering if the bug fixed with the following patch is the culprit: dillon 2001/01/29 00:19:28 PST Revision Changes Path 1.149 +17 -8 src/sys/miscfs/specfs/spec_vnops.c Does anyone know if umounting immediately after heavy IO could cause a SU-enabled filesystem to become mangled, if the above bug still exists? The first time, I was able to repair the fs, leaving some files in place and some in lost+found, but the next two times the filesystem was basically unrecoverable. The current fs had a usage of no more than 5%, but fsck is now reporting that "there is no more room in lost+found" . Obviously, I can't mount it up to check on it. I should mention that the last two crashes occured when testing filesystem extention using vinum/growfs, but I never got to the end. The last test I started with a 2 disk mirror, dropped one, created a striped plex with two drives, attached the plex to the mail volume and started it. During the remirror, I did some IO on the volume to simulate a live fs (I was pleased to see both drives of the new plex were getting IO), and when the mirror sync was finished, I umounted the fs, ran fsck, and found it scrambled. I was going to drop the original plex, add another drive, and reattach, but never got the chance. During none of my examinations, however, did it appear that vinum was involved. Does anyone have any reommendations? I have a trace of the first panic, a trace and a kernel crash dump from the second panic, and I still have the corrupt fs from the third test, plus I have my shell history from newfs to crash on the 3rd test. If anyone would find these useful please let me know. I should mention that we have almost 300G of space on freebsd fss that have had no problems. However, I'd like to be able to get to the bottom of this problem before bringing up the mail server. ---------------------------------------------------------------------- | Jim Hranicky, Senior SysAdmin UF/CISE Department | | E314D CSE Building Phone (352) 392-1499 | | jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh | ---------------------------------------------------------------------- - Encryption: its use by criminals is far less - - frightening than its banishment by governments - - Vote for Privacy - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 20 12:56:53 2001 Delivered-To: freebsd-fs@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 35F7337B491 for ; Tue, 20 Feb 2001 12:56:48 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f1KKukx95036; Tue, 20 Feb 2001 21:56:46 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "James F. Hranicky" Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Softupdates umount bug? Or vinum problem? In-Reply-To: Your message of "Tue, 20 Feb 2001 15:25:24 EST." <20010220202525.090D5DCC3@mail.cise.ufl.edu> Date: Tue, 20 Feb 2001 21:56:46 +0100 Message-ID: <95034.982702606@critter> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You may want to try to look at the commit mckusic did this morning/night/whatever, it looked like it had something to do with this problem. Poul-Henning In message <20010220202525.090D5DCC3@mail.cise.ufl.edu>, "James F. Hranicky" writes: > >Over the past few weeks, I've been playing around with a filesystem >destined to become our mail filesystem, doing things like turning >softupdates on/off, and setting various other fs options. All in >all, a lot of mounting/umounting, etc. > >Three times now, something I've done has caused the filesystem to >become corrupt, twice beyond repair. The first two times caused a panic, >and the third time, I simply unmounted the filesystem after some >IO and ran fsck, and got a badly mangled filesystem. > >I'm wondering if the bug fixed with the following patch is the >culprit: > > dillon 2001/01/29 00:19:28 PST > Revision Changes Path > 1.149 +17 -8 src/sys/miscfs/specfs/spec_vnops.c > >Does anyone know if umounting immediately after heavy IO could >cause a SU-enabled filesystem to become mangled, if the above >bug still exists? > >The first time, I was able to repair the fs, leaving some files >in place and some in lost+found, but the next two times the filesystem >was basically unrecoverable. The current fs had a usage of no more >than 5%, but fsck is now reporting that "there is no more room in >lost+found" . Obviously, I can't mount it up to check on it. > >I should mention that the last two crashes occured when testing >filesystem extention using vinum/growfs, but I never got to the end. >The last test I started with a 2 disk mirror, dropped one, created >a striped plex with two drives, attached the plex to the mail volume >and started it. During the remirror, I did some IO on the volume to >simulate a live fs (I was pleased to see both drives of the new plex >were getting IO), and when the mirror sync was finished, I umounted >the fs, ran fsck, and found it scrambled. I was going to drop the original >plex, add another drive, and reattach, but never got the chance. >During none of my examinations, however, did it appear that vinum >was involved. > >Does anyone have any reommendations? I have a trace of the first panic, >a trace and a kernel crash dump from the second panic, and I still >have the corrupt fs from the third test, plus I have my shell history >from newfs to crash on the 3rd test. If anyone would find these useful >please let me know. > >I should mention that we have almost 300G of space on freebsd fss that >have had no problems. However, I'd like to be able to get to the bottom >of this problem before bringing up the mail server. > >---------------------------------------------------------------------- >| Jim Hranicky, Senior SysAdmin UF/CISE Department | >| E314D CSE Building Phone (352) 392-1499 | >| jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh | >---------------------------------------------------------------------- > - Encryption: its use by criminals is far less - > - frightening than its banishment by governments - > - Vote for Privacy - > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-fs" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 20 19:28:50 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by hub.freebsd.org (Postfix) with ESMTP id C224237B4EC; Tue, 20 Feb 2001 19:28:45 -0800 (PST) (envelope-from res03db2@gte.net) Received: from gte.net (evrtwa1-ar4-4-34-145-186.dsl.gtei.net [4.34.145.186]) by smtppop3pub.verizon.net with ESMTP ; id VAA115565693 Tue, 20 Feb 2001 21:23:58 -0600 (CST) Received: (from res03db2@localhost) by gte.net (8.9.3/8.9.3) id TAA19229; Tue, 20 Feb 2001 19:27:55 -0800 (PST) (envelope-from res03db2@gte.net) Date: Tue, 20 Feb 2001 19:27:55 -0800 From: Robert Clark To: Terry Lambert Cc: Russell Cattelan , freebsd-chat@FreeBSD.ORG, Jack Rusher , Sam Leffler , Zhiui Zhang , freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system Message-ID: <20010220192755.B19188@darkstar.gte.net> References: <3A8396B9.CA8C09E4@thebarn.com> <200102090856.BAA08304@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200102090856.BAA08304@usr08.primenet.com>; from tlambert@primenet.com on Fri, Feb 09, 2001 at 08:56:29AM +0000 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry, Did you hear anything positive from SGI about the possibility of porting XFS? [RC] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 20 20: 4:36 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id D333937B401; Tue, 20 Feb 2001 20:04:30 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id VAA16760; Tue, 20 Feb 2001 21:01:24 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAAMa4MG; Tue Feb 20 21:01:15 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id VAA06482; Tue, 20 Feb 2001 21:04:11 -0700 (MST) From: Terry Lambert Message-Id: <200102210404.VAA06482@usr05.primenet.com> Subject: Re: Design a journalled file system To: res03db2@gte.net (Robert Clark) Date: Wed, 21 Feb 2001 04:04:06 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), cattelan@thebarn.com (Russell Cattelan), freebsd-chat@FreeBSD.ORG, jar@integratus.com (Jack Rusher), sam@errno.com (Sam Leffler), zzhang@cs.binghamton.edu (Zhiui Zhang), freebsd-fs@FreeBSD.ORG In-Reply-To: <20010220192755.B19188@darkstar.gte.net> from "Robert Clark" at Feb 20, 2001 07:27:55 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Terry, > Did you hear anything positive from SGI > about the possibility of porting XFS? > [RC] The last thing I heard was a second hand offer to consider releasing under a different license, with the requirement that someone couldn't make the thing into a product on its own. I don't really have parameters beyond that. It appears to me that the LGPL would be unacceptable, from that standpoint. If they are willing to have it be part of a larger product (my thinking here is that they want indemnification, which comes easily that way), then there are some obvious ways to write the license. IBM Alphaworks, and Sun's SLPv1 license has a similar restriction on "this can't be a product, without additional work". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Feb 20 22:22:11 2001 Delivered-To: freebsd-fs@freebsd.org Received: from lupo.thebarn.com (nic-31-c12-219.mn.mediaone.net [24.31.12.219]) by hub.freebsd.org (Postfix) with ESMTP id 2EDCA37B4EC; Tue, 20 Feb 2001 22:22:03 -0800 (PST) (envelope-from cattelan@thebarn.com) Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130]) by lupo.thebarn.com (8.11.2/8.11.0) with ESMTP id f1L6Lof04033; Wed, 21 Feb 2001 00:21:50 -0600 (CST) (envelope-from cattelan@thebarn.com) Message-ID: <3A936CFC.DE5F3775@thebarn.com> Date: Wed, 21 Feb 2001 01:23:41 -0600 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Robert Clark , freebsd-chat@FreeBSD.ORG, Jack Rusher , Sam Leffler , Zhiui Zhang , freebsd-fs@FreeBSD.ORG Subject: Re: Design a journalled file system References: <200102210404.VAA06482@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry nothing new to report. I've been looking over other open source licenses in the hope of finding examples to start drafting a workable license for XFS on BSD. Sorry folks this is going to be a slow process. Terry Lambert wrote: > > Terry, > > Did you hear anything positive from SGI > > about the possibility of porting XFS? > > [RC] > > The last thing I heard was a second hand offer to consider > releasing under a different license, with the requirement > that someone couldn't make the thing into a product on its > own. > > I don't really have parameters beyond that. It appears to > me that the LGPL would be unacceptable, from that standpoint. > > If they are willing to have it be part of a larger product > (my thinking here is that they want indemnification, which > comes easily that way), then there are some obvious ways to > write the license. IBM Alphaworks, and Sun's SLPv1 license > has a similar restriction on "this can't be a product, without > additional work". > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Feb 21 6: 3:39 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.cise.ufl.edu (beach.cise.ufl.edu [128.227.205.211]) by hub.freebsd.org (Postfix) with ESMTP id 72C2737B4EC for ; Wed, 21 Feb 2001 06:03:28 -0800 (PST) (envelope-from jfh@cise.ufl.edu) Received: from cise.ufl.edu (waterspout.cise.ufl.edu [128.227.205.52]) by mail.cise.ufl.edu (Postfix) with ESMTP id 8AF89D80A for ; Wed, 21 Feb 2001 09:03:26 -0500 (EST) To: freebsd-fs@FreeBSD.ORG Subject: Re: Softupdates umount bug? Or vinum problem? In-Reply-To: Message from Poul-Henning Kamp of "Tue, 20 Feb 2001 21:56:46 +0100." <95034.982702606@critter> Date: Wed, 21 Feb 2001 09:03:26 -0500 From: "James F. Hranicky" Message-Id: <20010221140326.8AF89D80A@mail.cise.ufl.edu> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Poul-Henning Kamp wrote: > > You may want to try to look at the commit mckusic did this > morning/night/whatever, it looked like it had something to > do with this problem. Is there a time frame for either of these patches making their way into -stable (I don't see either going into releng_4) ? Or can anyone suggest a workaround (e.g., run sync 10 times before umounting) ? Or, should I just disable softupdates for now (bummer)? I'm willing to do more testing and work with anyone who's interested. BTW, all my testing has been on 4.2-STABLE, with latest crash occuring on this rev: FreeBSD 4.2-STABLE #1: Thu Feb 15 11:31:58 EST 2001 I'm including all the info I mentioned in my first post here. Jim -------------------------------------------------------------------- Trace of 1st crash: ------------------- db> trace Debugger(c0338723) at Debugger+0x34 panic(c0358bc7,ce22b400,d6f42d74,c02ad4dc,c7606800) at panic+0x70 ufs_dirbad(c7606800,400,c0358b70,0,d6f9b240) at ufs_dirbad+0x3a ufs_lookup(d6f42db0,d6f42dc4,c01bf226,d6f42db0,d6f9b240) at ufs_lookup+0x260 ufs_vnoperate(d6f42db0,d6f9b240,d6e3d403,d6f42eac,c02b2715) at ufs_vnoperate+0x15 vfs_cache_lookup(d6f42e08,d6f42e18,c01c1fc4,d6f42e08,d6f9b240) at vfs_cache_lookup+0x28a ufs_vnoperate(d6f42e08,d6f9b240,c74bf600,d6f42eac,d6e6bbe0) at ufs_vnoperate+0x15 lookup(d6f42e84,d6e6bbe0,d6e6bbe0,d6f42f80,d6e6bbe0) at lookup+0x290 namei(d6f42e84,d6e6bbe0,2,d6f42f80,809c340) at namei+0x178 stat(d6e6bbe0,d6f42f80,809c348,809e080,809c300) at stat+0x41 syscall2(2f,2f,2f,809c300,809e080) at syscall2+0x1f1 Xint0x80_syscall() at Xint0x80_syscall+0x25 Unfortunately, I don't have a dump. Trace of 2nd crash + shell commands: ------------------------------------ # mount /export/mail # mount /dev/da0s1a on / (ufs, local) /dev/da0s1f on /private (ufs, local) /dev/da0s1e on /var (ufs, local) procfs on /proc (procfs, local) /dev/vinum/mail on /export/mail (ufs, NFS exported, local, soft-updates) # tunefs -p /export/mail tunefs: soft updates: (-n) enabled tunefs: maximum contiguous block count: (-a) 15 tunefs: rotational delay between contiguous blocks: (-d) 0 ms tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: minimum percentage of free space: (-m) 1% tunefs: optimization preference: (-o) time tunefs: should optimize for space with minfree < 8% [ Seeing if I could optimize for time with 1% minfree -- no. ] # time /var/tmp/make_imap_files /cise/mail/mhspool/aa1 done [ crash ] db> trace Debugger(c033bf63) at Debugger+0x34 panic(c035a1e1,c035a1c0,41c0,7ada80,c70618d4) at panic+0x70 ffs_valloc(d724ad00,41ed,c732c600,d6f01d08,d6f01e70) at ffs_valloc+0xf8 ufs_mkdir(d6f01e70,d6f01f2c,c01ccc9a,d6f01e70,d6e58d40) at ufs_mkdir+0x85 ufs_vnoperate(d6f01e70,d6e58d40,2,d6f01f80,c0374780) at ufs_vnoperate+0x15 mkdir(d6e58d40,d6f01f80,8099030,4,8099037) at mkdir+0x162 syscall2(2f,2f,2f,8099037,4) at syscall2+0x1f1 Xint0x80_syscall() at Xint0x80_syscall+0x25 Here's the make_imap_script (I'll be running uw-imapd with mods for MH mailboxes): #/bin/sh ypcat passwd | grep tcsh | perl -nle 'print "$1 $2" if (m,^(\S+):\S+:(\d+:\d+):,)' | \ sort -u | egrep '^[abc]' | while read user ugid ; do mkdir -p $top/$user/Mail/inbox # # Tar about 1000 files into the user's mailbox for testing purposes # # Approx time to untar: # # Vol with two 1 drive plexes: 2-3 seconds # Vol with two 2 drive striped plexes: 1 second # ( cd $top/$user/Mail/inbox ; tar xfBp /tmp/c.tar ) /usr/bin/printf '%s\n%s\n%s\n' 'Path: Mail' 'draft-folder: drafts' 'unseen-sequence: unseen ' > \ $top/$user/.mh_profile ; /usr/sbin/chown -R $ugid $top/$user /bin/chmod -R go-rwx $top/$user echo $top/$user done done This runs for about 2300 users, generating quite a bit of fs activity. In this case, I'm only creating the accounts beginning with [abc] though... Info from the dump of the second crash: --------------------------------------- # gdb -k kernel.debug /var/crash/vmcore.1 GNU gdb 4.18 [ ... ] IdlePTD 4567040 initial pcb at 3a6000 panicstr: ffs_valloc: dup alloc panic messages: --- panic: ffs_valloc: dup alloc syncing disks... 47 15 7 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 giving up on 2 buffers Uptime: 9h59m26s dumping to dev #da/0x20001, offset 1572992 dump 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 --- #0 dumpsys () at /private/freebsd-src/src/sys/kern/kern_shutdown.c:469 469 if (dumping++) { (kgdb) where #0 dumpsys () at /private/freebsd-src/src/sys/kern/kern_shutdown.c:469 #1 0xc019bd63 in boot (howto=256) at /private/freebsd-src/src/sys/kern/kern_shutdown.c:309 #2 0xc019c0f9 in panic (fmt=0xc035a1e1 "ffs_valloc: dup alloc") at /private/freebsd-src/src/sys/kern/kern_shutdown.c:556 #3 0xc02a4054 in ffs_valloc (pvp=0xd724ad00, mode=16877, cred=0xc732c600, vpp=0xd6f01d08) at /private/freebsd-src/src/sys/ufs/ffs/ffs_alloc.c:609 #4 0xc02b5c25 in ufs_mkdir (ap=0xd6f01e70) at /private/freebsd-src/src/sys/ufs/ufs/ufs_vnops.c:1310 #5 0xc02b6cbd in ufs_vnoperate (ap=0xd6f01e70) at /private/freebsd-src/src/sys/ufs/ufs/ufs_vnops.c:2287 #6 0xc01ccc9a in mkdir (p=0xd6e58d40, uap=0xd6f01f80) at vnode_if.h:653 #7 0xc03004ed in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134844471, tf_esi = 4, tf_ebp = -1077937700, tf_isp = -688906284, tf_ebx = 134844464, tf_edx = 134844464, tf_ecx = 4, tf_eax = 136, tf_trapno = 7, tf_err = 2, tf_eip = 134605108, tf_cs = 31, tf_eflags = 518, tf_esp = -1077938064, tf_ss = 47}) at /private/freebsd-src/src/sys/i386/i386/trap.c:1150 #8 0xc02f1ca5 in Xint0x80_syscall () #9 0x8050a1d in ?? () #10 0x8052da2 in ?? () #11 0x8048135 in ?? () (kgdb) up #1 0xc019bd63 in boot (howto=256) at /private/freebsd-src/src/sys/kern/kern_shutdown.c:309 309 dumpsys(); (kgdb) #2 0xc019c0f9 in panic (fmt=0xc035a1e1 "ffs_valloc: dup alloc") at /private/freebsd-src/src/sys/kern/kern_shutdown.c:556 556 boot(bootopt); (kgdb) #3 0xc02a4054 in ffs_valloc (pvp=0xd724ad00, mode=16877, cred=0xc732c600, vpp=0xd6f01d08) at /private/freebsd-src/src/sys/ufs/ffs/ffs_alloc.c:609 609 panic("ffs_valloc: dup alloc"); (kgdb) list 604 } 605 ip = VTOI(*vpp); 606 if (ip->i_mode) { 607 printf("mode = 0%o, inum = %lu, fs = %s\n", 608 ip->i_mode, (u_long)ip->i_number, fs->fs_fsmnt); -->609 panic("ffs_valloc: dup alloc"); 610 } 611 if (ip->i_blocks) { /* XXX */ 612 printf("free inode %s/%lu had %ld blocks\n", 613 fs->fs_fsmnt, (u_long)ino, (long)ip->i_blocks); (kgdb) up #4 0xc02b5c25 in ufs_mkdir (ap=0xd6f01e70) at /private/freebsd-src/src/sys/ufs/ufs/ufs_vnops.c:1310 1310 error = UFS_VALLOC(dvp, dmode, cnp->cn_cred, &tvp); (kgdb) list 1305 /* 1306 * Must simulate part of ufs_makeinode here to acquire the inode, 1307 * but not have it entered in the parent directory. The entry is 1308 * made later after writing "." and ".." entries. 1309 */ -->1310 error = UFS_VALLOC(dvp, dmode, cnp->cn_cred, &tvp); 1311 if (error) 1312 goto out; 1313 ip = VTOI(tvp); 1314 ip->i_gid = dp->i_gid; Shell history of 3rd fs crash: ------------------------------ newfs -v -i 2048 -m 1 /dev/vinum/mail fsck /dev/vinum/mail [ ok ] tunefs -n enable /export/mail tunefs -n enable /dev/vinum/mail fsck /dev/vinum/mail [ ok ] tunefs -p /dev/vinum/mail tunefs -o time /dev/vinum/mail [ fs changed back to space during fs IO ] vi /etc/fstab mount /export/mail df -k showmount -e cd /export/mail ls cd time /var/tmp/make_imap_files cat > /var/tmp/mkimf0 vinum list more /tmp/mail.p1 vinum create -f /tmp/mail.p1 vinum list vinum attach mail.p1 mail vinum start mail.p1 vinum list find /export/mail [ ok ] time /var/tmp/make_imap_files rm -rf /cise/mail/mhspool/a* vinum list man iostat iostat -n 5 1 ls -d /cise/mail/mhspool/a* rm -rf /cise/mail/mhspool/[bc]* vinum list time /var/tmp/make_imap_files vinum list cat > /var/tmp/mkimf1 vinum list vinum list vinum list vinum list vinum list vinum list vinum list vinum list vinum list vinum list vinum list [ waited for mirror to sync up, between 1-2 hours ] df -k /export/mail [ seemed ok ] umount /export/mail fsck /dev/vinum/mail [ failed, many errors ] mount /export/mail [ failed ] vinum list echo '***** filesystem dead *****' I went ahead and ran fsck again just now (Wed morning). Here are the highlights (3M worth of output). fsck output: --------------- 70578 DUP I=31872 UNEXPECTED SOFT UPDATE INCONSISTENCY 70579 DUP I=31872 UNEXPECTED SOFT UPDATE INCONSISTENCY 70580 DUP I=31873 UNEXPECTED SOFT UPDATE INCONSISTENCY 70581 DUP I=31873 [....] UNEXPECTED SOFT UPDATE INCONSISTENCY 1806410 DUP I=849031 UNEXPECTED SOFT UPDATE INCONSISTENCY INTERNAL ERROR: dups with -p [....] UNEXPECTED SOFT UPDATE INCONSISTENCY UNALLOCATED NAME=/lost+found/#01311046 UNEXPECTED SOFT UPDATE INCONSISTENCY UNALLOCATED NAME=/lost+found/#01311043 [....] UNEXPECTED SOFT UPDATE INCONSISTENCY DUP/BAD FILE=/lost+found/#00370626 [....] I=1125952 OWNER=aarcot MODE=0 SIZE=0 MTIME=Feb 20 10:23 2001 REMOVE? yes [....] I=2175671 OWNER=cjn MODE=0 SIZE=0 MTIME=Feb 20 10:27 2001 COUNT 0 SHOULD BE -1 ADJUST? yes [....] ** Phase 5 - Check Cyl groups SALVAGE? yes SALVAGE? yes SALVAGE? yes (53252 frags, 4059511 blocks, 0.2% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** [ Seems like this is premature ] ***** FILE SYSTEM WAS MODIFIED ***** Here's what the dir looks like now: ----------------------------------- # ls /export/mail/mhspool aa1/ aesquive/ ajohnson/ amm/ aritter/ av0/ aa2/ aev/ ajp/ amolina/ arowan/ avance/ [....] adossani/ ajheim/ amlone/ aring/ aup/ inbox/ Many of the files were missing, and an inbox was put back in the wrong place. lost+found: # ls /export/mail/lost+found ls: #00354752: Bad file descriptor ls: #00539840: Bad file descriptor ls: #00802048: Bad file descriptor [30 lines of that, then many # files] # /bin/ls -1 | wc -l 4449 I'm willing to do more looking around if somone can tell me where to look. -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Feb 21 10: 2:14 2001 Delivered-To: freebsd-fs@freebsd.org Received: from sistina.com (hermes.sistina.com [208.210.145.141]) by hub.freebsd.org (Postfix) with SMTP id 0E90037B401 for ; Wed, 21 Feb 2001 10:02:10 -0800 (PST) (envelope-from declerck@sistina.com) Received: (qmail 13265 invoked from network); 21 Feb 2001 18:01:28 -0000 Received: from fry.sistina.com (HELO sistina.com) (208.210.145.138) by hermes.sistina.com with SMTP; 21 Feb 2001 18:01:28 -0000 Received: by sistina.com (sSMTP sendmail emulation); Wed, 21 Feb 2001 12:02:07 -0600 From: Mike Declerck Date: Wed, 21 Feb 2001 12:02:07 -0600 To: freebsd-fs@freebsd.org Subject: Porting GFS to FreeBSD Message-Id: <20010221180210.0E90037B401@hub.freebsd.org> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org All, Sistina Software Inc is in the process of evaluating the effort to port the Global File System from Linux to FreeBSD. Before someone starts harping on the GPL let me state that Sistina is willing to have a separate license for the *BSD community so if we could put that discussion off to a later time I would appreciate it. For people who don't know about GFS you can find technical information concerning it at -> http://www.sistina.com Here is a quick description: The Global File System (GFS) is a shared disk cluster file system for Linux. GFS supports journaling and recovery from client failures. GFS cluster nodes physically share the same storage by means of Fibre Channel, shared SCSI devices or network block devices. The file system appears to be local on each node and GFS synchronizes file access across the cluster. GFS is fully symmetric, that is, all nodes are equal and there is no server which may be a bottleneck or single point of failure. GFS uses read and write caching while maintaining full UNIX file system semantics. Sistina is looking at porting to FreeBSD for a number of reasons: o Despite the fact that Linux gets most of the press concerning Open Source OS penetration into the enterprise Sistina is aware of *BSD penetration as well. In fact, at Linux World Expo we had a number of large enterprise companies approach us about GFS running on FreeBSD. Hence we would like to have a presence in FreeBSD o GFS has two main goals. Obviously we have other goals but these are from the 10,000 ft view. 1) To be a high performance cluster file system 2) To be a cluster file system that runs in heterogenous environments (hence why we want to port to FreeBSD). o FreeBSD is closer to the mainstream Unices so a port to FreeBSD will help us abstract our code base and make it easier to port to other OSs. What I would like to find out from the list is: o Is there any interest in having GFS ported to FreeBSD (I believe there is)? o Is there a particular FreeBSD market segment that would be more open than others in looking at a cluster/cluster FS environent (http, smtp, imap clusters) o Is there anyone in the FreeBSD community willing to work with us (either for pay or as an open source participant) on the port? o Are there any FreeBSD enterprise entities who might be willing to fund the port? Sorry if this sounds like a troll or advertisement but I need this information to justify to my management and Board of Directors assigning resources to the port. --- Michael Declerck, declerck@sistina.com +1.510.823.7991 Director of Open Source Development To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Feb 21 13:57:26 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 23DE137B4EC for ; Wed, 21 Feb 2001 13:57:22 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1LLvFf28585; Wed, 21 Feb 2001 13:57:20 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102212157.f1LLvFf28585@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mike Declerck Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Porting GFS to FreeBSD In-Reply-To: <20010221180210.0E90037B401@hub.freebsd.org> Date: Wed, 21 Feb 2001 13:57:15 -0800 From: Peter Wemm Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Declerck wrote: > All, > > Sistina Software Inc is in the process of evaluating the effort to port the > Global File System from Linux to FreeBSD. Before someone starts harping on > the GPL let me state that Sistina is willing to have a separate license for > the *BSD community so if we could put that discussion off to a later time I > would appreciate it. > > For people who don't know about GFS you can find technical information > concerning it at -> http://www.sistina.com [With my Yahoo! hat on] Wow! The subject of GFS came up a few days ago, including the possibility of doing a port to FreeBSD ourselves if nothing else turned up. The timing of this is amazing! > What I would like to find out from the list is: > > o Is there any interest in having GFS ported to FreeBSD (I believe there is)? Count a definite Yes! from Yahoo. > o Is there a particular FreeBSD market segment that would be more open than > others in looking at a cluster/cluster FS environent (http, smtp, imap > clusters) We have a particular application in mind, but the whole SAN thing opens up a lot of possibilities in clusters, > o Is there anyone in the FreeBSD community willing to work with us (either for > pay or as an open source participant) on the port? The project has a number of people with expertise in the VFS area. > o Are there any FreeBSD enterprise entities who might be willing to fund the > port? There are a number of entities who would benefit from this. Many are used to providing support or assistance for making things happen. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed Feb 21 21:33:35 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.cise.ufl.edu (beach.cise.ufl.edu [128.227.205.211]) by hub.freebsd.org (Postfix) with ESMTP id A0EE437B4EC for ; Wed, 21 Feb 2001 21:33:25 -0800 (PST) (envelope-from jfh@cise.ufl.edu) Received: from cise.ufl.edu (waterspout.cise.ufl.edu [128.227.205.52]) by mail.cise.ufl.edu (Postfix) with ESMTP id 631B4DCD9 for ; Thu, 22 Feb 2001 00:33:23 -0500 (EST) To: freebsd-fs@freebsd.org Subject: Re: Softupdates umount bug? Or vinum problem? In-Reply-To: Message from "James F. Hranicky" of "Wed, 21 Feb 2001 09:03:26 EST." <20010221140326.8AF89D80A@mail.cise.ufl.edu> Date: Thu, 22 Feb 2001 00:33:23 -0500 From: "James F. Hranicky" Message-Id: <20010222053323.631B4DCD9@mail.cise.ufl.edu> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I stress tested a new fs for about 4 hours, creating and removing 100,000+ files at a time, and all went well until I tried to add a larger plex to the vinum volume. This time, I got a crash in the vinum routines: db> trace dscheck(c6f70e20,c7cc0500) at dscheck+0x104 diskstrategy(c6f70e20,c705c880,c7058800,cc1918b0,c796bd80) at diskstrategy+0x7d launch_requests(c796bd80,0,cc1918b0,d70adec0,0) at launch_requests+0x2f7 vinumstart(cc1918b0,0,cc1918b0,d7106c68,c01d2b14) at vinumstart+0x1ce vinumstrategy(cc1918b0,c7064680,d7106ce0,cc1918b0,d7106c74) at vinumstrategy+0x96 spec_strategy(d7106c98,d7106c80,c02b6ced,d7106c98,d7106ca4) at spec_strategy+0x8c spec_vnoperate(d7106c98,d7106ca4,c01bf77e,d7106c98,c7cbe700) at spec_vnoperate+0x15 ufs_vnoperatespec(d7106c98) at ufs_vnoperatespec+0x15 bread(d70adec0,1a0040,2000,0,d7106ce0) at bread+0x8e ffs_vget(c7fa0c00,61e80,d7106d58,0,d7310d40) at ffs_vget+0x1ce ufs_lookup(d7106db0,d7106dc4,c01c32be,d7106db0,d7310d40) at ufs_lookup+0x9ad ufs_vnoperate(d7106db0,d7310d40,d6eee01b,d7106eac,d79ea440) at ufs_vnoperate+0x15 vfs_cache_lookup(d7106e08,d7106e18,c01c6084,d7106e08,d5a5be00) at vfs_cache_lookup+0x28a ufs_vnoperate(d7106e08,d5a5be00,d6eee000,d7106eac,d6e57ea0) at ufs_vnoperate+0x15 lookup(d7106e84,d6e57ea0,2,d6e57ea0,d6e57ea0) at lookup+0x290 namei(d7106e84,d6e57ea0,2,d7106f80,807d540) at namei+0x178 lstat(d6e57ea0,d7106f80,807d55c,807b000,807d500) at lstat+0x41 syscall2(2f,2f,2f,807d500,807b000) at syscall2+0x1f1 Xint0x80_syscall() at Xint0x80_syscall+0x25 db> c Fatal trap 12: page fault while in kernel mode fault virtual address = 0x3a32ca5b fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a5818 stack pointer = 0x10:0xd7106bcc frame pointer = 0x10:0xd7106be0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 24383 (rm) interrupt mask = none kernel: type 12 trap, code=0 Stopped at dscheck+0x104: movl 0xb8(%esi),%edx db> c I wasn't able to continue, so I couldn't get a dump. Here's (hopefully) the relevant info: - FreeBSD-STABLE 2/15 - vinum list (prior to the addition of the plex): # vinum list 4 drives: D d1 State: down Device /dev/da1s1e Avail: 0/35000 MB (0%) D d2 State: down Device /dev/da2s1e Avail: 35000/35000 MB (100%) D d3 State: down Device /dev/da3s1e Avail: 0/35000 MB (0%) D d4 State: down Device /dev/da4s1e Avail: 0/35000 MB (0%) 1 volumes: V mail State: up Plexes: 2 Size: 68 GB 2 plexes: P mail.p0 C State: up Subdisks: 1 Size: 34 GB P mail.p1 S State: up Subdisks: 2 Size: 68 GB 3 subdisks: S mail.p0.s0 State: up PO: 0 B Size: 34 GB S mail.p1.s0 State: up PO: 0 B Size: 34 GB S mail.p1.s1 State: up PO: 256 kB Size: 34 GB - vinum history excerpt 21 Feb 2001 15:42:55.860262 *** vinum started *** 21 Feb 2001 15:42:55.887197 start 21 Feb 2001 15:42:56.295117 *** Created devices *** 21 Feb 2001 15:43:49.435252 *** vinum started *** 21 Feb 2001 15:43:49.435719 start 21 Feb 2001 15:45:33.081283 *** vinum started *** 21 Feb 2001 15:45:33.081784 list 21 Feb 2001 15:46:04.679306 *** vinum started *** 21 Feb 2001 15:46:04.679796 stop mail.p1 21 Feb 2001 15:46:09.565558 *** vinum started *** 21 Feb 2001 15:46:09.566115 rm -rf mail.p1 21 Feb 2001 15:46:11.084216 *** vinum started *** 21 Feb 2001 15:46:11.084728 list [ softupdates test runs during this time, no problems ] 21 Feb 2001 19:00:40.873656 *** vinum started *** 21 Feb 2001 19:00:40.910968 list 21 Feb 2001 19:01:00.353893 *** vinum started *** 21 Feb 2001 19:01:00.354407 create -f /tmp/mail.p1 drive d1 device /dev/da1s1e drive d2 device /dev/da2s1e drive d3 device /dev/da3s1e drive d4 device /dev/da4s1e plex name mail.p1 org striped 256k sd name mail.p1.s0 length 0g drive d3 sd name mail.p1.s1 length 0g drive d4 21 Feb 2001 19:01:00.362798 *** Created devices *** 21 Feb 2001 19:01:45.423633 *** vinum started *** 21 Feb 2001 19:01:45.451875 attach mail.p1 mail 21 Feb 2001 19:01:49.437425 *** vinum started *** 21 Feb 2001 19:01:49.438050 list 21 Feb 2001 19:01:56.013097 *** vinum started *** 21 Feb 2001 19:01:56.017289 start mail.p1 21 Feb 2001 19:02:21.175751 *** vinum started *** 21 Feb 2001 19:02:21.191962 rm -rf mail.p1 21 Feb 2001 19:02:24.727802 *** vinum started *** 21 Feb 2001 19:02:24.728401 list 21 Feb 2001 19:02:29.647423 *** vinum started *** 21 Feb 2001 19:02:29.647976 list 21 Feb 2001 19:02:54.096393 *** vinum started *** 21 Feb 2001 19:02:54.118180 create -f /tmp/mail.p1 drive d1 device /dev/da1s1e drive d2 device /dev/da2s1e drive d3 device /dev/da3s1e drive d4 device /dev/da4s1e plex name mail.p1 org striped 256k sd name mail.p1.s0 length 0g drive d3 sd name mail.p1.s1 length 0g drive d4 21 Feb 2001 19:02:54.124947 *** Created devices *** 21 Feb 2001 19:02:58.361927 *** vinum started *** 21 Feb 2001 19:02:58.362543 attach 21 Feb 2001 19:03:10.799338 *** vinum started *** 21 Feb 2001 19:03:10.803315 attach mail.p1 mail 21 Feb 2001 19:03:13.595055 *** vinum started *** 21 Feb 2001 19:03:13.595758 list 21 Feb 2001 19:03:25.612261 *** vinum started *** 21 Feb 2001 19:03:25.628535 start mail.p1 21 Feb 2001 19:03:29.242104 *** vinum started *** 21 Feb 2001 19:03:29.242695 start mail.p1.s0 21 Feb 2001 19:04:38.466545 *** vinum started *** 21 Feb 2001 19:04:38.470618 info 21 Feb 2001 19:04:41.256836 *** vinum started *** 21 Feb 2001 19:04:41.257616 list 21 Feb 2001 19:04:44.347045 *** vinum started *** 21 Feb 2001 19:04:44.347707 list -V [ crash ] 21 Feb 2001 20:25:27.714923 *** vinum started *** 21 Feb 2001 20:25:27.723779 start 21 Feb 2001 20:26:56.869531 *** vinum started *** 21 Feb 2001 20:26:56.877844 list 21 Feb 2001 20:27:05.500935 *** vinum started *** 21 Feb 2001 20:27:05.501432 list 21 Feb 2001 20:27:23.784211 *** vinum started *** 21 Feb 2001 20:27:23.784716 stop mail.p1 21 Feb 2001 20:27:51.053214 *** vinum started *** 21 Feb 2001 20:27:51.053726 rm -rf mail.p1 21 Feb 2001 20:27:53.015977 *** vinum started *** 21 Feb 2001 20:27:53.016477 list 21 Feb 2001 20:34:51.023524 *** vinum started *** 21 Feb 2001 20:34:51.024037 list 21 Feb 2001 20:35:29.883130 *** vinum started *** 21 Feb 2001 20:35:29.883651 start d1 21 Feb 2001 20:35:32.740364 *** vinum started *** 21 Feb 2001 20:35:32.740895 list 21 Feb 2001 20:35:37.722339 *** vinum started *** 21 Feb 2001 20:35:37.722839 start d2 21 Feb 2001 20:35:38.772824 *** vinum started *** 21 Feb 2001 20:35:38.773334 start d3 21 Feb 2001 20:35:39.739196 *** vinum started *** 21 Feb 2001 20:35:39.739699 start d3=4 21 Feb 2001 20:35:42.224147 *** vinum started *** 21 Feb 2001 20:35:42.224650 start d4 21 Feb 2001 20:35:45.687607 *** vinum started *** 21 Feb 2001 20:35:45.688110 list 21 Feb 2001 20:42:34.205088 *** vinum started *** 21 Feb 2001 20:42:34.205594 list 21 Feb 2001 20:44:13.507914 *** vinum started *** 21 Feb 2001 20:44:13.508425 list -V 21 Feb 2001 20:44:55.647243 *** vinum started *** 21 Feb 2001 20:44:55.647759 read 21 Feb 2001 20:44:59.402924 *** vinum started *** 21 Feb 2001 20:44:59.403434 read da1 21 Feb 2001 20:45:04.688342 *** vinum started *** 21 Feb 2001 20:45:04.688846 read da1s1 21 Feb 2001 20:45:08.132045 *** vinum started *** 21 Feb 2001 20:45:08.132575 read /dev/da1s1 21 Feb 2001 20:45:12.547624 *** vinum started *** 21 Feb 2001 20:45:12.548132 read /dev/da1s1e 21 Feb 2001 20:45:12.640094 *** Created devices *** 21 Feb 2001 20:45:17.569063 *** vinum started *** 21 Feb 2001 20:45:17.569575 read /dev/da2s1e 21 Feb 2001 20:45:21.030786 *** vinum started *** 21 Feb 2001 20:45:21.031301 read /dev/da3s1e [ I think it was with one of these commands I managed to get /dev/da1s1e to show up like so: D d1 State: down Device /dev/da1s1es1a Avail: 35000/35000 MB (100%) Also, all of my vinum drives were marked down, and I had to bring them up again by hand. ] - messages Feb 21 19:01:20 dogwood /kernel: vinum: mail.p1.s0 is up Feb 21 19:01:20 dogwood /kernel: vinum: mail.p1.s1 is up Feb 21 19:01:20 dogwood /kernel: vinum: mail.p1 is up Feb 21 19:01:55 dogwood /kernel: vinum: mail.p1.s0 is up Feb 21 19:01:55 dogwood /kernel: vinum: mail.p1.s1 is up Feb 21 19:01:55 dogwood /kernel: vinum: mail.p1 is faulty Feb 21 19:02:25 dogwood /kernel: vinum: removing mail.p1 Feb 21 19:02:25 dogwood /kernel: vinum: invalid plex type 0 in bre Feb 21 19:02:55 dogwood /kernel: vinum: mail.p1.s0 is up Feb 21 19:02:55 dogwood /kernel: vinum: mail.p1.s1 is up Feb 21 19:02:55 dogwood /kernel: vinum: mail.p1 is up Feb 21 19:03:20 dogwood /kernel: vinum: mail.p1.s0 is up Feb 21 19:03:20 dogwood /kernel: vinum: mail.p1.s1 is up Feb 21 19:03:20 dogwood /kernel: vinum: mail.p1 is faulty [ crash ] Feb 21 20:25:29 dogwood /kernel: Copyright (c) 1992-2001 The FreeBSD Project. Feb 21 20:25:29 dogwood /kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Feb 21 20:25:29 dogwood /kernel: The Regents of the University of California. All rights reserved. Feb 21 20:25:29 dogwood /kernel: FreeBSD 4.2-STABLE #1: Thu Feb 15 11:31:58 EST 2001 Feb 21 20:25:29 dogwood /kernel: root@palm.cise.ufl.edu:/private/freebsd-src/obj/private/freebsd-src/src/sys/CISEKERN Feb 21 20:25:29 dogwood /kernel: Timecounter "i8254" frequency 1193182 Hz Feb 21 20:25:29 dogwood /kernel: CPU: Pentium III/Pentium III Xeon/Celeron (646.67-MHz 686-class CPU) Feb 21 20:25:29 dogwood /kernel: Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Feb 21 20:25:29 dogwood /kernel: Features=0x387fbff Feb 21 20:25:29 dogwood /kernel: real memory = 268369920 (262080K bytes) [ ... ] Feb 21 20:25:29 dogwood /kernel: da0 at ahc2 bus 0 target 0 lun 0 Feb 21 20:25:29 dogwood /kernel: da0: Fixed Direct Access SCSI-3 device Feb 21 20:25:29 dogwood /kernel: da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled Feb 21 20:25:29 dogwood /kernel: da0: 8759MB (17938986 512 byte sectors: 255H 63S/T 1116C) Feb 21 20:25:29 dogwood /kernel: da1 at ahc1 bus 0 target 0 lun 0 Feb 21 20:25:29 dogwood /kernel: da1: Fixed Direct Access SCSI-3 device Feb 21 20:25:29 dogwood /kernel: da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled Feb 21 20:25:29 dogwood /kernel: da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) Feb 21 20:25:29 dogwood /kernel: da4 at ahc1 bus 0 target 3 lun 0 Feb 21 20:25:29 dogwood /kernel: da4: Fixed Direct Access SCSI-3 device Feb 21 20:25:29 dogwood /kernel: da4: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled Feb 21 20:25:29 dogwood /kernel: da4: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) Feb 21 20:25:29 dogwood /kernel: da3 at ahc1 bus 0 target 2 lun 0 Feb 21 20:25:29 dogwood /kernel: da3: Fixed Direct Access SCSI-3 device Feb 21 20:25:29 dogwood /kernel: da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled Feb 21 20:25:29 dogwood /kernel: da3: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) Feb 21 20:25:29 dogwood /kernel: da2 at ahc1 bus 0 target 1 lun 0 Feb 21 20:25:29 dogwood /kernel: da2: Fixed Direct Access SCSI-3 device Feb 21 20:25:29 dogwood /kernel: da2: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled Feb 21 20:25:29 dogwood /kernel: da2: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) Feb 21 20:25:29 dogwood /kernel: Mounting root from ufs:/dev/da0s1a Feb 21 20:25:29 dogwood /kernel: WARNING: / was not properly dismounted Feb 21 20:25:29 dogwood savecore: no core dump Feb 21 20:25:33 dogwood named[266]: starting (/etc/namedb/named.conf). named 8.2.3-REL Thu Feb 15 10:16:56 EST 2001 root@palm.cise.ufl.edu:/private/freebsd-src/obj/private/freebsd-src/src/usr.sbin/named Feb 21 20:25:33 dogwood named[266]: limit files set to fdlimit (1024) Feb 21 20:25:33 dogwood named[266]: Zone "0.0.127.in-addr.arpa" (file 127.0.0.rev): No default TTL ($TTL ) set, using SOA minimum instead Feb 21 20:25:33 dogwood named[266]: 127.0.0.rev: WARNING SOA expire value is less than 7 days (360000) Feb 21 20:25:33 dogwood named[267]: Ready to answer queries. Feb 21 20:25:33 dogwood rpc.lockd[286]: Couldn't find lockd in services. Assuming port 4045. Feb 21 20:27:29 dogwood /kernel: vinum: mail.p1.s0 is down by force Feb 21 20:27:29 dogwood /kernel: vinum: mail.p1 is faulty Feb 21 20:27:29 dogwood /kernel: vinum: mail.p1.s1 is down by force Feb 21 20:27:29 dogwood /kernel: vinum: mail.p1 is faulty Feb 21 20:27:59 dogwood /kernel: vinum: removing mail.p1 Feb 21 20:30:15 dogwood ntpd[409]: time reset 0.185618 s Feb 21 20:30:15 dogwood ntpd[409]: kernel pll status change 2041 Feb 21 20:35:44 dogwood /kernel: vinum: drive d1 is up Feb 21 20:35:44 dogwood /kernel: vinum: drive d2 is up Feb 21 20:35:44 dogwood /kernel: vinum: drive d3 is up Feb 21 20:35:44 dogwood /kernel: vinum: drive d4 is up Feb 21 20:43:08 dogwood login: ROOT LOGIN (root) ON ttyd0 Feb 21 20:45:00 dogwood /kernel: vinum: Can't open drive without drive name Feb 21 20:45:00 dogwood last message repeated 34 times Feb 21 20:45:00 dogwood /kernel: vinum: no drives found Feb 21 20:45:30 dogwood /kernel: vinum: Can't open drive without drive name Feb 21 20:45:30 dogwood last message repeated 34 times Feb 21 20:45:30 dogwood /kernel: vinum: no drives found Feb 21 20:45:30 dogwood /kernel: vinum: no drives found Feb 21 20:45:30 dogwood /kernel: vinum: updating configuration from /dev/da1s1es1a Feb 21 20:45:30 dogwood /kernel: vinum: no drives found Feb 21 20:45:30 dogwood last message repeated 2 times Feb 21 20:48:30 dogwood /kernel: vinum: already read config from d1 Feb 21 20:48:30 dogwood /kernel: vinum: no drives found Feb 21 20:50:40 dogwood ntpd[409]: time reset -0.184934 s I can try to duplicate this tomorrow, if that would be helpful. Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 22 3:41:20 2001 Delivered-To: freebsd-fs@freebsd.org Received: from hermes.mixx.net (hermes.mixx.net [212.84.196.2]) by hub.freebsd.org (Postfix) with ESMTP id 64B5337B401 for ; Thu, 22 Feb 2001 03:41:16 -0800 (PST) (envelope-from news-list.freebsd.fs@innominate.de) Received: from mate.bln.innominate.de (cerberus.berlin.innominate.de [212.84.234.251]) by hermes.mixx.net (Postfix) with ESMTP id E1BE3F807 for ; Thu, 22 Feb 2001 12:41:14 +0100 (CET) Received: by mate.bln.innominate.de (Postfix, from userid 9) id ABE752CA70; Thu, 22 Feb 2001 12:41:14 +0100 (CET) From: Thomas Graichen Reply-To: Thomas Graichen X-Newsgroups: innominate.bln.list.freebsd.fs Subject: Re: Porting GFS to FreeBSD Date: 22 Feb 2001 11:41:14 GMT Organization: innominate AG, Berlin, Germany Lines: 38 Distribution: local Message-ID: References: <20010221180210.0E90037B401@hub.freebsd.org> X-Trace: mate.bln.innominate.de 982842074 6564 10.0.0.31 (22 Feb 2001 11:41:14 GMT) X-Complaints-To: news@innominate.de User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.1-XFS (i686)) To: fs@FreeBSD.org Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Declerck wrote: > All, > Sistina Software Inc is in the process of evaluating the effort to port the > Global File System from Linux to FreeBSD. Before someone starts harping on > the GPL let me state that Sistina is willing to have a separate license for > the *BSD community so if we could put that discussion off to a later time I > would appreciate it. > For people who don't know about GFS you can find technical information > concerning it at -> http://www.sistina.com > Here is a quick description: > The Global File System (GFS) is a shared disk cluster file system for Linux. > GFS supports journaling and recovery from client failures. GFS cluster nodes > physically share the same storage by means of Fibre Channel, shared SCSI > devices or network block devices. The file system appears to be local on each > node and GFS synchronizes file access across the cluster. GFS is fully > symmetric, that is, all nodes are equal and there is no server which may be a > bottleneck or single point of failure. GFS uses read and write caching while > maintaining full UNIX file system semantics. i think also important to note here (for all who don't know GFS well) that GFS is also useable quite well as a local filesystem - that means porting it to FreeBSD would result in a journaling 64bit (ok - no problem for FreeBSD :o) filesystem which also can handle large directories very well ... i think beneath the really cool aspect of a clustered filesystem this is also something which looks pretty interesting t -- thomas.graichen@innominate.com innominate AG the linux architects tel: +49-30-308806-13 fax: -77 http://www.innominate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 22 13:35:32 2001 Delivered-To: freebsd-fs@freebsd.org Received: from knight.phoenix.volant.org (knight.phoenix.volant.org [205.179.79.194]) by hub.freebsd.org (Postfix) with ESMTP id 2C94B37B401 for ; Thu, 22 Feb 2001 13:35:31 -0800 (PST) (envelope-from patl@phoenix.volant.org) Received: from patl by knight.phoenix.volant.org with local (Exim 3.20 #1) id 14W3Rg-000NBy-00 for freebsd-fs@freebsd.org; Thu, 22 Feb 2001 13:38:40 -0800 To: freebsd-fs@freebsd.org Subject: Status of nullfs Message-Id: From: Pat Lashley Date: Thu, 22 Feb 2001 13:38:40 -0800 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The man page in -STABLE for mount_null contains dire warnings about its lack of support and potential to cause problems. But how solid/shakey is it really? Is it, in practice, safe to use? Is there any particular usage that is more likely to cause problems, or are the warnings just there because nobody is actively keeping it up to date? In other words, if I'm willing to take the risk of using it, just how big of a risk am I actually taking? Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 22 14:15:34 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 3E58237B401 for ; Thu, 22 Feb 2001 14:15:31 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id PAA20561; Thu, 22 Feb 2001 15:12:24 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAviaagO; Thu Feb 22 15:12:17 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA26750; Thu, 22 Feb 2001 15:15:19 -0700 (MST) From: Terry Lambert Message-Id: <200102222215.PAA26750@usr05.primenet.com> Subject: Re: Status of nullfs To: patl@phoenix.volant.org (Pat Lashley) Date: Thu, 22 Feb 2001 22:14:48 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: from "Pat Lashley" at Feb 22, 2001 01:38:40 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The man page in -STABLE for mount_null contains dire warnings about > its lack of support and potential to cause problems. But how > solid/shakey is it really? Is it, in practice, safe to use? Is > there any particular usage that is more likely to cause problems, > or are the warnings just there because nobody is actively keeping > it up to date? > > In other words, if I'm willing to take the risk of using it, just > how big of a risk am I actually taking? Any mmap'ed writes will fail due to cache coherency problems. If the system isn't quiescent long enough to flush everything out before an unmount, you can panic. If you have exposed the NULL mount , e.g. by mounting an FS on /usr, and then nullfs mounting it to /null_usr, then modifications to the /usr FS will not result in coherency notification, and files will become corrupt, if accessed both ways. Paging from executables can cause problems for multiple copies of executables, if statically initialized data is modified (copy on write) due to the way backing page handling is limited. All of these derive from the fact that the vnode in the upper layer (nullfs) and the vnode in the lower layer (ffs or whatever) have seperate vm_object_t's, even though the data contents of the file are supposed to be treated as identical for both. There are a number of patches to manually enforce coherency; as far as I know, they don't deal with the pager path, and, since the coherency is explicit, the /usr vs. /null_usr problem is not resolved. Check the list archives to obtain the patches. If you need stacking for a project, FiST has been ported to FreeBSD. Personally, I have not used it, but supposedly it addresses the vm_object_t aliasing caused coherency problems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 22 15:47:51 2001 Delivered-To: freebsd-fs@freebsd.org Received: from phoenix.volant.org (dickson.phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 85FC537B4EC for ; Thu, 22 Feb 2001 15:47:48 -0800 (PST) (envelope-from patl@Phoenix.Volant.ORG) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 14W5Se-0001rl-00; Thu, 22 Feb 2001 15:47:48 -0800 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.3+Sun/8.9.3) with SMTP id PAA11565; Thu, 22 Feb 2001 15:47:10 -0800 (PST) From: patl@Phoenix.Volant.ORG Date: Thu, 22 Feb 2001 15:47:10 -0800 (PST) Reply-To: patl@Phoenix.Volant.ORG Subject: Re: Status of nullfs To: Terry Lambert Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <200102222215.PAA26750@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22-Feb-01 at 14:15, Terry Lambert (tlambert@primenet.com) wrote: > Any mmap'ed writes will fail due to cache coherency problems. If > ... > file are supposed to be treated as identical for both. Thanks, Terry. Given your clear and concise explanation, I don't think that nullfs will be suitable for my use. > There are a number of patches to manually enforce coherency; as > far as I know, they don't deal with the pager path, and, since > the coherency is explicit, the /usr vs. /null_usr problem is > not resolved. Check the list archives to obtain the patches. > > If you need stacking for a project, FiST has been ported to > FreeBSD. Personally, I have not used it, but supposedly it > addresses the vm_object_t aliasing caused coherency problems. Hmm. That looks like it might be a possibility; I'll look into it a bit deeper. Of course I might be on completely the wrong tack. I'm looking into methods to reduce the disk overhead and maintainance issues with setting up jailed virtual hosts. The hosts generally won't have any user shell access; but will run some combination of SMTP, IMAP, POP, FTP, HTTP, etc. services. It seems like it should be possible to set up a prototype jail directory tree with all of the necessary software installed. That directory should be shared read-only with all jails; with each jail having a read-write filesystem layered on top with the necessary per-virtual-host configuration and data files. It would be even better if there were two per-jail layers, one underneath with config files, read-only, and the one on top for data files read-write. But a single per-jail layer would be OK. Ideally, root on the host machine should have read-write access to both the shared prototype and the 'raw' overlayed directories. (By 'raw', I mean only what is actually in the overlayed tree, without the prototype underneath.) The raw access isn't really necessary; but it would make a few things easier. I'll be happy to hear of any suggestions on how to do this on 4-STABLE; or any reasonable alternative schemes to accomplish the same goal. Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 22 18:42:45 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 7A9A237B401 for ; Thu, 22 Feb 2001 18:42:36 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f1N2gUf43386; Thu, 22 Feb 2001 18:42:31 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200102230242.f1N2gUf43386@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Terry Lambert Cc: patl@phoenix.volant.org (Pat Lashley), freebsd-fs@FreeBSD.ORG Subject: Re: Status of nullfs In-Reply-To: <200102222215.PAA26750@usr05.primenet.com> Date: Thu, 22 Feb 2001 18:42:30 -0800 From: Peter Wemm Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: > > The man page in -STABLE for mount_null contains dire warnings about > > its lack of support and potential to cause problems. But how > > solid/shakey is it really? Is it, in practice, safe to use? Is > > there any particular usage that is more likely to cause problems, > > or are the warnings just there because nobody is actively keeping > > it up to date? > > > > In other words, if I'm willing to take the risk of using it, just > > how big of a risk am I actually taking? > > Any mmap'ed writes will fail due to cache coherency problems. If > the system isn't quiescent long enough to flush everything out > before an unmount, you can panic. If you have exposed the NULL > mount , e.g. by mounting an FS on /usr, and then nullfs mounting > it to /null_usr, then modifications to the /usr FS will not > result in coherency notification, and files will become corrupt, > if accessed both ways. Paging from executables can cause problems > for multiple copies of executables, if statically initialized data > is modified (copy on write) due to the way backing page handling > is limited. > > All of these derive from the fact that the vnode in the upper > layer (nullfs) and the vnode in the lower layer (ffs or whatever) > have seperate vm_object_t's, even though the data contents of the > file are supposed to be treated as identical for both. Terry, please check your facts. This has been recently fixed. See the VOP_GETVOBJECT() stuff. The trick though is to get it MFC'ed into 4.x... > There are a number of patches to manually enforce coherency; as > far as I know, they don't deal with the pager path, and, since > the coherency is explicit, the /usr vs. /null_usr problem is > not resolved. Check the list archives to obtain the patches. nullfs is fully functional in -current. Backporting the changes should be easy. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 22 19:27:31 2001 Delivered-To: freebsd-fs@freebsd.org Received: from phoenix.volant.org (dickson.phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 8AC2537B491 for ; Thu, 22 Feb 2001 19:27:26 -0800 (PST) (envelope-from patl@Phoenix.Volant.ORG) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 14W8tB-0002Qi-00; Thu, 22 Feb 2001 19:27:25 -0800 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.3+Sun/8.9.3) with SMTP id TAA11841; Thu, 22 Feb 2001 19:26:42 -0800 (PST) From: patl@Phoenix.Volant.ORG Date: Thu, 22 Feb 2001 19:26:42 -0800 (PST) Reply-To: patl@Phoenix.Volant.ORG Subject: Re: Status of nullfs To: Peter Wemm Cc: tlambert@primenet.com, freebsd-fs@FreeBSD.ORG In-Reply-To: <200102230242.f1N2gUf43386@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 22-Feb-01 at 18:42, Peter Wemm (peter@netplex.com.au) wrote: > > Any mmap'ed writes will fail due to cache coherency problems. If > > the system isn't quiescent long enough to flush everything out > > before an unmount, you can panic. If you have exposed the NULL > > mount , e.g. by mounting an FS on /usr, and then nullfs mounting > > it to /null_usr, then modifications to the /usr FS will not > > result in coherency notification, and files will become corrupt, > > if accessed both ways. Paging from executables can cause problems > > for multiple copies of executables, if statically initialized data > > is modified (copy on write) due to the way backing page handling > > is limited. > > > > All of these derive from the fact that the vnode in the upper > > layer (nullfs) and the vnode in the lower layer (ffs or whatever) > > have seperate vm_object_t's, even though the data contents of the > > file are supposed to be treated as identical for both. > > Terry, please check your facts. This has been recently fixed. See the > VOP_GETVOBJECT() stuff. The trick though is to get it MFC'ed into > 4.x... In Terry's support, I -was- specificly asking about -STABLE. > > There are a number of patches to manually enforce coherency; as > > far as I know, they don't deal with the pager path, and, since > > the coherency is explicit, the /usr vs. /null_usr problem is > > not resolved. Check the list archives to obtain the patches. > > nullfs is fully functional in -current. Backporting the changes should > be easy. Hmm. Easy for someone familiar with the kernel internals; or easy for someone with 30 years of systems level software engineering experience but -no- unix kernel experience? (If the later, I may see if I can free up the cycles to do it. If the former, I doubt that I'll get enough cycles to climb that specific learning curve before other priorities intervene.) -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 22 21:49:24 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id C1E5F37B491 for ; Thu, 22 Feb 2001 21:49:20 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id WAA42138; Thu, 22 Feb 2001 22:48:54 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdTqBQqa; Thu Feb 22 22:48:46 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA09447; Thu, 22 Feb 2001 22:49:03 -0700 (MST) From: Terry Lambert Message-Id: <200102230549.WAA09447@usr05.primenet.com> Subject: Re: Status of nullfs To: peter@netplex.com.au (Peter Wemm) Date: Fri, 23 Feb 2001 05:49:03 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), patl@phoenix.volant.org (Pat Lashley), freebsd-fs@FreeBSD.ORG In-Reply-To: <200102230242.f1N2gUf43386@mobile.wemm.org> from "Peter Wemm" at Feb 22, 2001 06:42:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Terry, please check your facts. This has been recently fixed. See the > VOP_GETVOBJECT() stuff. The trick though is to get it MFC'ed into > 4.x... Cool; I was unaware that this had been done. This was even the approach I advocated from a casual look at it on the CVS web. Last I had heard of this, people were still advocating alias objects. Things like this should really be talked about on the -FS list, don't you think? -- Realize that I don't run 5.x these days, since it's not distributed as a release yet. He also can't run it, if it's going to be a production environment, since it's too unstable (library stuff, etc.). > > There are a number of patches to manually enforce coherency; as > > far as I know, they don't deal with the pager path, and, since > > the coherency is explicit, the /usr vs. /null_usr problem is > > not resolved. Check the list archives to obtain the patches. > > nullfs is fully functional in -current. Backporting the changes should > be easy. It would be cool if someone could do this; I'm currently busy dealing with other fires. I stole an hour and a half tonight (more on that in a minute). From what he needs it for, you could also diddle the mount tab to implement the equivalent of a Solaris "loopback" mount, where you externalize the same FS in multiple locations. You would need to take special care with the ".." transition over the mount point, though, to make sure you didn't end up out of your jail, and in someone else's (might be done automatically; I have no idea whether the .. is handled by backing over the matching mount point (which would be "the first matching" in this case), or whether it uses the covered vnode based on the mount instance. This would be a very easy, low cost approach to making an R/O FS appear in more than one place. This would effectively be sililar to the -union option (as opposed to using a unionfs). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu Feb 22 22: 7:57 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 8A33337B491 for ; Thu, 22 Feb 2001 22:07:53 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id XAA24391; Thu, 22 Feb 2001 23:02:12 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAjAaWKV; Thu Feb 22 23:02:06 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id XAA09891; Thu, 22 Feb 2001 23:07:42 -0700 (MST) From: Terry Lambert Message-Id: <200102230607.XAA09891@usr05.primenet.com> Subject: Re: Porting GFS to FreeBSD To: declerck@sistina.com (Mike Declerck) Date: Fri, 23 Feb 2001 06:07:41 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <20010221180210.0E90037B401@hub.freebsd.org> from "Mike Declerck" at Feb 21, 2001 12:02:07 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Sistina Software Inc is in the process of evaluating the effort to port the > Global File System from Linux to FreeBSD. Before someone starts harping on > the GPL let me state that Sistina is willing to have a separate license for > the *BSD community so if we could put that discussion off to a later time I > would appreciate it. OK, I stole an hour and a half from myself tonight, and hacked on the src/tools code. I have about 20k of patches against the 4.x distribution that's sitting out there as "4.0", and need an FTP incoming to upload them too (or I can send a 20K email to someone who cares). I did *NOT* start with the CVS sources. The patches are to make it compile on FreeBSD 4.1, following a configure, and using gmake, since the configure doesn't appear to generate portable Makefiles. Should work on 4.2, will probably fail for some dumb reason on -current. I used the disklabel ioctl() to get the number of 512b sectors on the device, since it appears from looking at the disk drivers that spit out the sizes for dmesg, that the in-core label will have the correct value for this. I also fixed portability issues in all the files I touched, and there is some room for some common code that isn't common (I put in #warning for that). I tried to stick to the coding style already in the files, but I am a bad boy when it comes to spacing around parenthesis, a hard habit to break, so don't be surprised if there's some of that crept in. Let me know if you want the code... and if so, how best to get it to you. -- Here is the current status: Tools; "OK" means "compiles and appears to run"; special devices are not present. ------------- ------------------------------------------------ tool status ------------- ------------------------------------------------ gclient OK gfs_expand OK gfs_jadd OK gfsconf OK gserv OK hexedit OK initds OK pinfo OK assemble OK mkfs OK (don't remember for sure) mountgfs NEEDS KERNEL CODE AND AT LEAST A PARTIAL REWRITE dmep_tools NEEDS CAM CONVERSION gfs_tool FILE "gfs_debug.h" MISSING FROM DISTRIBUTION gfsck FILE "gfs_debug.h" MISSING FROM DISTRIBUTION ptool NEEDS LINUX SPINLOCK CODE EQUIVALENT test_dmep NEEDS CAM CONVERSION ucmemexp OK ------------- ------------------------------------------------ Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Feb 23 0:26:10 2001 Delivered-To: freebsd-fs@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id E982037B491; Fri, 23 Feb 2001 00:26:05 -0800 (PST) (envelope-from keichii@peorth.iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 35FDC59525; Fri, 23 Feb 2001 02:26:16 -0600 (CST) Date: Fri, 23 Feb 2001 02:26:16 -0600 From: "Michael C . Wu" To: current@freebsd.org Cc: fs@freebsd.org Subject: FFS snapshot with today's CURRENT freezes and reboots. Message-ID: <20010223022616.A28598@peorth.iteration.net> Reply-To: "Michael C . Wu" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, I hate to do an 'as title' post. However, I did a make world about 6 hours ago. And when I execute mount snapshot -u -o /xxx/snap1 /xxx The machine always freezes for about 15 seconds and reboots without warning. This is a Sony VAIO laptop z505js with ATA disk. (if that is even of relevance). Since I discovered the problem at 1am, I really have no other debug information to be put up, just a heads up. I am wondering if this is just me, or is anybody having the same problem? If this problem is repeatable for others, I'll generate a bug report that will make Bill Paul smile. :) -- +------------------------------------------------------------------+ | keichii@peorth.iteration.net | keichii@bsdconspiracy.net | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Feb 23 3:34:22 2001 Delivered-To: freebsd-fs@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 5F8D237B401 for ; Fri, 23 Feb 2001 03:34:16 -0800 (PST) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 89DA528D48; Fri, 23 Feb 2001 17:34:05 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 82D2128D17; Fri, 23 Feb 2001 17:34:05 +0600 (ALMT) Date: Fri, 23 Feb 2001 17:34:05 +0600 (ALMT) From: Boris Popov To: Terry Lambert Cc: Peter Wemm , Pat Lashley , freebsd-fs@FreeBSD.ORG Subject: Re: Status of nullfs In-Reply-To: <200102230549.WAA09447@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 23 Feb 2001, Terry Lambert wrote: > > Terry, please check your facts. This has been recently fixed. See the > > VOP_GETVOBJECT() stuff. The trick though is to get it MFC'ed into > > 4.x... > > Cool; I was unaware that this had been done. This was even the > approach I advocated from a casual look at it on the CVS web. > Last I had heard of this, people were still advocating alias > objects. > > Things like this should really be talked about on the -FS list, > don't you think? Well, they was and I'm recall that you even replied to my post :) See http://www.freebsd.org/cgi/getmsg.cgi?fetch=0+0+/usr/local/www/db/text/2000/freebsd-fs/20000910.freebsd-fs for start of the thread. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Feb 23 7:57:57 2001 Delivered-To: freebsd-fs@freebsd.org Received: from sistina.com (hermes.sistina.com [208.210.145.141]) by hub.freebsd.org (Postfix) with SMTP id C5F5E37B401 for ; Fri, 23 Feb 2001 07:57:55 -0800 (PST) (envelope-from declerck@sistina.com) Received: (qmail 24783 invoked from network); 23 Feb 2001 15:57:12 -0000 Received: from fry.sistina.com (HELO sistina.com) (208.210.145.138) by hermes.sistina.com with SMTP; 23 Feb 2001 15:57:12 -0000 Received: by sistina.com (sSMTP sendmail emulation); Fri, 23 Feb 2001 09:57:53 -0600 From: Mike Declerck Date: Fri, 23 Feb 2001 09:57:53 -0600 To: freebsd-fs@freebsd.org Subject: Re: Porting GFS to FreeBSD Message-Id: <20010223155755.C5F5E37B401@hub.freebsd.org> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry, Great! We (Sistina) definitely want the patches. I am forwarding your message to a set of my key developers. One of them will contact you shortly about how the patches can be submitted. tlambert@primenet.com said: > OK, I stole an hour and a half from myself tonight, and hacked on the > src/tools code. > I have about 20k of patches against the 4.x distribution that's > siting out there as "4.0", and need an FTP incoming to upload them > too (or I can send a 20K email to someone who cares). --- Michael Declerck, declerck@sistina.com +1.510.823.7991 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Feb 23 10:50:19 2001 Delivered-To: freebsd-fs@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 93E4A37B401 for ; Fri, 23 Feb 2001 10:50:16 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id TAA50423; Fri, 23 Feb 2001 19:50:11 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Pat Lashley Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Status of nullfs References: From: Dag-Erling Smorgrav Date: 23 Feb 2001 19:50:10 +0100 In-Reply-To: Pat Lashley's message of "Thu, 22 Feb 2001 13:38:40 -0800" Message-ID: Lines: 14 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Pat Lashley writes: > The man page in -STABLE for mount_null contains dire warnings about > its lack of support and potential to cause problems. But how > solid/shakey is it really? Is it, in practice, safe to use? The null filesystem type is not yet fully supported (read: it doesn't work) and using it may, in fact, destroy data on your system. Use at your own risk. Beware of dog. Slippery when wet. :) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Feb 23 13:16:34 2001 Delivered-To: freebsd-fs@freebsd.org Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by hub.freebsd.org (Postfix) with ESMTP id 7547837B401 for ; Fri, 23 Feb 2001 13:16:30 -0800 (PST) (envelope-from cattelan@thebarn.com) Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA18447; Fri, 23 Feb 2001 13:15:23 -0800 (PST) mail_from (cattelan@thebarn.com) Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA49168; Fri, 23 Feb 2001 15:16:26 -0600 (CST) Received: from thebarn.com (localhost [127.0.0.1]) by gibble.americas.sgi.com (8.11.2/8.11.2) with ESMTP id f1NLFKq18201; Fri, 23 Feb 2001 16:15:20 -0500 Message-ID: <3A96D2E6.7D21753D@thebarn.com> Date: Fri, 23 Feb 2001 16:15:18 -0500 From: Russell Cattelan X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Mike Declerck , freebsd-fs@FreeBSD.ORG Subject: Re: Porting GFS to FreeBSD References: <200102230607.XAA09891@usr05.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Terry Lambert wrote: BTW if anybody wants the code from the first time this port was started let me know. I did have it to the point where is was reading the superblock and mounting. Obviously the code is way out of sync but the vfs/vnode interface it there and mostly working. > > Sistina Software Inc is in the process of evaluating the effort to port the > > Global File System from Linux to FreeBSD. Before someone starts harping on > > the GPL let me state that Sistina is willing to have a separate license for > > the *BSD community so if we could put that discussion off to a later time I > > would appreciate it. > > OK, I stole an hour and a half from myself tonight, and hacked on > the src/tools code. > > I have about 20k of patches against the 4.x distribution that's > sitting out there as "4.0", and need an FTP incoming to upload > them too (or I can send a 20K email to someone who cares). > > I did *NOT* start with the CVS sources. > > The patches are to make it compile on FreeBSD 4.1, following > a configure, and using gmake, since the configure doesn't appear > to generate portable Makefiles. Should work on 4.2, will > probably fail for some dumb reason on -current. > > I used the disklabel ioctl() to get the number of 512b sectors > on the device, since it appears from looking at the disk drivers > that spit out the sizes for dmesg, that the in-core label will > have the correct value for this. I also fixed portability issues > in all the files I touched, and there is some room for some > common code that isn't common (I put in #warning for that). > > I tried to stick to the coding style already in the files, but > I am a bad boy when it comes to spacing around parenthesis, a > hard habit to break, so don't be surprised if there's some of > that crept in. > > Let me know if you want the code... and if so, how best to get > it to you. > > -- > > Here is the current status: > > Tools; "OK" means "compiles and appears to run"; special devices > are not present. > > ------------- ------------------------------------------------ > tool status > ------------- ------------------------------------------------ > gclient OK > gfs_expand OK > gfs_jadd OK > gfsconf OK > gserv OK > hexedit OK > initds OK > pinfo OK > assemble OK > mkfs OK (don't remember for sure) > mountgfs NEEDS KERNEL CODE AND AT LEAST A PARTIAL REWRITE > dmep_tools NEEDS CAM CONVERSION > gfs_tool FILE "gfs_debug.h" MISSING FROM DISTRIBUTION > gfsck FILE "gfs_debug.h" MISSING FROM DISTRIBUTION > ptool NEEDS LINUX SPINLOCK CODE EQUIVALENT > test_dmep NEEDS CAM CONVERSION > ucmemexp OK > ------------- ------------------------------------------------ > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- Russell Cattelan -- Digital Elves inc. -- Currently on loan to SGI Linux XFS core developer. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Feb 23 13:19:55 2001 Delivered-To: freebsd-fs@freebsd.org Received: from sistina.com (hermes.sistina.com [208.210.145.141]) by hub.freebsd.org (Postfix) with SMTP id B950E37B503 for ; Fri, 23 Feb 2001 13:19:50 -0800 (PST) (envelope-from kpreslan@sistina.com) Received: (qmail 17785 invoked from network); 23 Feb 2001 21:18:23 -0000 Received: from fry.sistina.com (HELO sistina.com) (208.210.145.138) by hermes.sistina.com with SMTP; 23 Feb 2001 21:18:23 -0000 Received: by sistina.com (sSMTP sendmail emulation); Fri, 23 Feb 2001 15:19:04 -0600 From: Ken Preslan Date: Fri, 23 Feb 2001 15:19:04 -0600 To: Russell Cattelan Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Porting GFS to FreeBSD Message-ID: <20010223151904.A12469@sistina.com> References: <200102230607.XAA09891@usr05.primenet.com> <3A96D2E6.7D21753D@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A96D2E6.7D21753D@thebarn.com>; from cattelan@thebarn.com on Fri, Feb 23, 2001 at 04:15:18PM -0500 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It's all still in the attic of the public CVS repository: http://www.globalfilesystem.org/cgi-bin/cvsweb.cgi/GFS/src/fs/arch_freebsd/Attic/ On Fri, Feb 23, 2001 at 04:15:18PM -0500, Russell Cattelan wrote: > Terry Lambert wrote: > > BTW if anybody wants the code from the first time this port was started let me > know. > > I did have it to the point where is was reading the superblock and mounting. > > Obviously the code is way out of sync but the vfs/vnode interface it there and > mostly working. > > > > > Sistina Software Inc is in the process of evaluating the effort to port the > > > Global File System from Linux to FreeBSD. Before someone starts harping on > > > the GPL let me state that Sistina is willing to have a separate license for > > > the *BSD community so if we could put that discussion off to a later time I > > > would appreciate it. > > > > OK, I stole an hour and a half from myself tonight, and hacked on > > the src/tools code. > > > > I have about 20k of patches against the 4.x distribution that's > > sitting out there as "4.0", and need an FTP incoming to upload > > them too (or I can send a 20K email to someone who cares). > > > > I did *NOT* start with the CVS sources. > > > > The patches are to make it compile on FreeBSD 4.1, following > > a configure, and using gmake, since the configure doesn't appear > > to generate portable Makefiles. Should work on 4.2, will > > probably fail for some dumb reason on -current. > > > > I used the disklabel ioctl() to get the number of 512b sectors > > on the device, since it appears from looking at the disk drivers > > that spit out the sizes for dmesg, that the in-core label will > > have the correct value for this. I also fixed portability issues > > in all the files I touched, and there is some room for some > > common code that isn't common (I put in #warning for that). > > > > I tried to stick to the coding style already in the files, but > > I am a bad boy when it comes to spacing around parenthesis, a > > hard habit to break, so don't be surprised if there's some of > > that crept in. > > > > Let me know if you want the code... and if so, how best to get > > it to you. > > > > -- > > > > Here is the current status: > > > > Tools; "OK" means "compiles and appears to run"; special devices > > are not present. > > > > ------------- ------------------------------------------------ > > tool status > > ------------- ------------------------------------------------ > > gclient OK > > gfs_expand OK > > gfs_jadd OK > > gfsconf OK > > gserv OK > > hexedit OK > > initds OK > > pinfo OK > > assemble OK > > mkfs OK (don't remember for sure) > > mountgfs NEEDS KERNEL CODE AND AT LEAST A PARTIAL REWRITE > > dmep_tools NEEDS CAM CONVERSION > > gfs_tool FILE "gfs_debug.h" MISSING FROM DISTRIBUTION > > gfsck FILE "gfs_debug.h" MISSING FROM DISTRIBUTION > > ptool NEEDS LINUX SPINLOCK CODE EQUIVALENT > > test_dmep NEEDS CAM CONVERSION > > ucmemexp OK > > ------------- ------------------------------------------------ > > > > Terry Lambert > > terry@lambert.org > > --- > > Any opinions in this posting are my own and not those of my present > > or previous employers. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-fs" in the body of the message > > -- > Russell Cattelan > -- > Digital Elves inc. -- Currently on loan to SGI > Linux XFS core developer. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- Ken Preslan Code Monkey Sistina Software, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message