From owner-freebsd-fs Mon May 7 23:33: 4 2001 Delivered-To: freebsd-fs@freebsd.org Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.130.111.12]) by hub.freebsd.org (Postfix) with ESMTP id 4087F37B423; Mon, 7 May 2001 23:32:58 -0700 (PDT) (envelope-from pfeifer@dbai.tuwien.ac.at) Received: from deneb (deneb [128.130.111.2]) by vexpert.dbai.tuwien.ac.at (8.11.1/8.11.1) with ESMTP id f486WaM22998; Tue, 8 May 2001 08:32:37 +0200 (MET DST) Date: Tue, 8 May 2001 08:32:36 +0200 (CEST) From: Gerald Pfeifer To: Dima Dorfman Cc: Boris Popov , Peter Pentchev , Bruce Evans , , , Subject: Re: Displaying options for current NFS mounts In-Reply-To: <20010325222920.D1E863E09@bazooka.unixfreak.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 What happened to this patch/this discussion? To remind everyone, the issue was to print specific file-system specific mount options as in dima@spike% /sbin/mount -vt nfs pid295@spike:/host on /host (nfs, v2, udp, hard, intr) pid295@spike:/st on /st (nfs, v2, udp, hard, intr) instead of just dima@spike% /sbin/mount -vt nfs pid295@spike:/host on /host (nfs) pid295@spike:/st on /st (nfs) Gerald On Sun, 25 Mar 2001, Dima Dorfman wrote: >Boris Popov writes: >> This is not a bikeshed, but sysctl is the wrong interface to do >> this. Use VFSs/VOPs instead. This isn't a big problem with passing string >> from kernel to userland. > > I like your idea of using the extattr interface. It isn't a perfect > match, since ideally this would be a VFS operation, but it works quite > well. The only modifications required are to mount(8) to try to get > this attribute, and then to any filesystem which wishes to support it. > > Below is a patch which makes the necessary changes to mount(8), and > adds support for this to NFS. It's amazingly simple, and doesn't > interfere with anything else (i.e., you don't have to rebuild half the > world to use it). The only thing I don't like is that the "mountopts" > and "mountopts_verbose" constants aren't macroized, but that can be > easily solved (I just didn't know where to put them). With it, > mount(8) outputs stuff like this: > > dima@spike% /sbin/mount -vt nfs > pid295@spike:/host on /host (nfs, v2, udp, hard, intr) > pid295@spike:/st on /st (nfs, v2, udp, hard, intr) > bazooka:/a on /.amd/bazooka/host/a (nfs, nodev, nosuid, v3, tcp, hard, intr) > bazooka:/b on /.amd/bazooka/host/b (nfs, nodev, nosuid, v3, tcp, hard, intr) > > Comments? Suggestions? > > Thanks in advance > > Dima Dorfman > dima@unixfreak.org > > P.S. Would anyone have a fit if I wrote man pages for > extattr_get_file, extattr_set_file, and extattr_delete_file? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue May 8 5:28:40 2001 Delivered-To: freebsd-fs@freebsd.org Received: from news.kiev.sovam.com (news.kiev.sovam.com [212.109.32.16]) by hub.freebsd.org (Postfix) with ESMTP id E782B37B424 for ; Tue, 8 May 2001 05:28:37 -0700 (PDT) (envelope-from gw-bsd-fs@news.kiev.sovam.com) Received: from mail by news.kiev.sovam.com with local (Exim 2.12 #1) id 14x6bO-000Pka-00 for freebsd-fs@freebsd.org; Tue, 8 May 2001 15:28:30 +0300 From: "Dmitry Alyabyev" To: freebsd-fs@freebsd.org Reply-To: "Dmitry Alyabyev" Subject: Ultra3 SCSI support Date: 8 May 2001 12:28:27 GMT Message-ID: <9d8opb$30l4$1@news.kiev.sovam.com> References: X-Organization: -None- X-Gated-By: news2list v1.4, (c) Vladimir Litovka X-Gated-Date: Tue May 8 12:28:30 2001 GMT Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy Does anybody know about full support of Ultra-3 SCSI devices in FBSD 4.2-ST ? I mean transfer on 160MB ... Thanks, -- Dimitry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Wed May 9 14:38:49 2001 Delivered-To: freebsd-fs@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id D1BB937B422; Wed, 9 May 2001 14:38:40 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 9 May 2001 22:38:39 +0100 (BST) To: freebsd-fs@freebsd.org Cc: phk@freebsd.org, iedowse@maths.tcd.ie Subject: vflush() Date: Wed, 09 May 2001 22:38:39 +0100 From: Ian Dowse Message-ID: <200105092238.aa48273@salmon.maths.tcd.ie> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The function vflush() is used by most filesystems in xxx_unmount() to clean out all vnodes associated with the filesystem. Normally it returns EBUSY if any vnodes have a non-zero reference count, but the FORCECLOSE flag overrides this, forcing a vgone() on all vnodes. Many filesystems have a natural reference count of 1 for the filesystem root vnode, so a non-forced vflush() would always fail. This situation is currently catered for by vflush's `skipvp' argument; when non-NULL, vflush() skips the specified vnode and lets the caller deal with it. A problem with this approach is that when a skipvp argument is supplied, the caller must re-implement vflush()'s logic for the root vnode, except that it must compare the reference count against 1 instead of 0. Currently all filesystems in the tree that make use of `skipvp' do this incorrectly. They check the reference count, but ignore FORCECLOSE, so if there are any extra references on the filesystem root directory vnode then the umount will fail even with FORCECLOSE specified. All of devfs, smbfs, fdesc, nullfs, portal, umapfs, union, nfs and nwfs have this problem. e.g in devfs: if (rootvp->v_usecount > 2) { vrele(rootvp); return (EBUSY); } error = vflush(mp, rootvp, flags); if (error) return (error); devfs_purge(fmp->dm_rootdir); vput(rootvp); vrele(rootvp); vgone(rootvp); In each and every filesystem in the tree that uses `skipvp': (a) it specifies the root vnode; (b) there are a fixed number of extra references; (c) the caller immediately releases all root vnode references when vflush() is successful. Also, vflush() is used exclusively by filesystem unmount() functions. All this suggests that vflush() should subsume the logic for dealing with the reference count on the filesystem root vnode. This would simplify the xxx_umount() functions and permits the FORCECLOSE problem to be solved for all 9 filesystems in one place. One possibility (which may be a bit too restrictive for future filesystems) is to replace vflush()'s `skipvp' argument with an integer specifying how many references should be both expected and removed from the filesystem root vnode. e.g: /* ... * `rootrefs' specifies the base reference count for the root vnode * of this filesystem. The root vnode is considered busy if its * v_usecount exceeds this value. On a successful return, vflush() * will call vrele() on the root vnode exactly rootrefs times. */ int vflush(struct mount *mp, int rootrefs, int flags) { That would simplify devfs_unmount() considerably: --- /usr/src/sys/fs/devfs/devfs_vfsops.c Tue May 8 18:59:58 2001 +++ /tmp/devfs_vfsops.c Wed May 9 21:57:45 2001 @@ -117,26 +117,16 @@ { int error; int flags = 0; - struct vnode *rootvp; struct devfs_mount *fmp; - error = devfs_root(mp, &rootvp); - if (error) - return (error); fmp = VFSTODEVFS(mp); if (mntflags & MNT_FORCE) flags |= FORCECLOSE; - if (rootvp->v_usecount > 2) { - vrele(rootvp); - return (EBUSY); - } - error = vflush(mp, rootvp, flags); + /* The root vnode has 1 extra reference to be removed. */ + error = vflush(mp, 1, flags); if (error) return (error); devfs_purge(fmp->dm_rootdir); - vput(rootvp); - vrele(rootvp); - vgone(rootvp); mp->mnt_data = 0; lockdestroy(&fmp->dm_lock); free(fmp, M_DEVFS); The changes needed to vflush() are along the lines of the patch below. Does this approach seem reasonable or any other comments? e.g. are the semantics of vflush() doing the vrele's itself too weird and restrictive? Ian --- /usr/src/sys/kern/vfs_subr.c Tue May 8 19:00:17 2001 +++ /tmp/vfs_subr.c Wed May 9 22:08:47 2001 @@ -1634,15 +1644,24 @@ #endif int -vflush(mp, skipvp, flags) +vflush(mp, rootrefs, flags) struct mount *mp; - struct vnode *skipvp; + int rootrefs; int flags; { struct proc *p = curproc; /* XXX */ - struct vnode *vp, *nvp; - int busy = 0; + struct vnode *vp, *nvp, *rootvp = NULL; + int baserefs, busy = 0, error; + if (rootrefs > 0) { + /* + * Get the filesystem root vnode. We can vput() it + * immediately, since with rootrefs > 0, it won't go away. + */ + if ((error = VFS_ROOT(mp, &rootvp)) != 0) + return (error); + vput(rootvp); + } mtx_lock(&mntvnode_mtx); loop: for (vp = LIST_FIRST(&mp->mnt_vnodelist); vp; vp = nvp) { @@ -1678,10 +1697,11 @@ } /* - * With v_usecount == 0, all we need to do is clear out the - * vnode data structures and we are done. + * With v_usecount == baserefs, all we need to do is clear + * out the vnode data structures and we are done. */ - if (vp->v_usecount == 0) { + baserefs = (vp == rootvp) ? rootrefs : 0; + if (vp->v_usecount == baserefs) { mtx_unlock(&mntvnode_mtx); vgonel(vp, p); mtx_lock(&mntvnode_mtx); @@ -1715,6 +1735,8 @@ mtx_unlock(&mntvnode_mtx); if (busy) return (EBUSY); + for (; rootrefs > 0; rootrefs--) + vrele(rootvp); return (0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Thu May 10 19:31:59 2001 Delivered-To: freebsd-fs@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id E4CB737B423 for ; Thu, 10 May 2001 19:31:54 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id TAA14475; Thu, 10 May 2001 19:31:50 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200105110231.TAA14475@beastie.mckusick.com> To: Alfred Perlstein Subject: Re: versioned files via snapshot evilness. Cc: Terry Lambert , fs@FreeBSD.ORG In-Reply-To: Your message of "Thu, 26 Apr 2001 11:10:11 PDT." <20010426111010.M18676@fw.wintelcom.net> Date: Thu, 10 May 2001 19:31:50 -0700 From: Kirk McKusick Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Date: Thu, 26 Apr 2001 11:10:11 -0700 From: Alfred Perlstein To: Terry Lambert Cc: mckusick@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: versioned files via snapshot evilness. * Terry Lambert [010426 10:46] wrote: > > I'm wondering if it might be possible to abuse the ffs snapshot > > stuff to do file versioning ala VMS. > > Not really, IMO. > > Versioning ala VMS requires kernel globbing, or amazingly > intrusive library modifications, coupled with a guarantee > by programmers that they will only use the preferred APIs > in their applications. > > Consider how you would make: > > fd = open( "foo", O_RDWR, 0); > > open version 17 of the file "foo", as opposed to an earlier version, > and how you would tag versions into the file names, without stealing > a character (e.g. ";"). Also note that "/" is valid in a UTF-8 > filename today, if it is part of a multibyte sequence (but FreeBSD > can not handle this). It would be nice if "foo" was the "HEAD" version of the file and each new open for write _could_ cause a foo;#ver or something to be created. I was asking more to find out the capabilities that snapshots brings versus the pre-existing limitations in the namespace code currently in place. More, can we snapshot individual files? -- -Alfred Perlstein - [alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ The way that snapshots are implemented, they only work for filesystems as a whole, not for individual files. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri May 11 7:41:51 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail-ob05.one.net.au (mail-ob05.one.net.au [61.12.0.165]) by hub.freebsd.org (Postfix) with ESMTP id 63D4E37B440; Fri, 11 May 2001 07:41:42 -0700 (PDT) (envelope-from adrirub@one.net.au) Received: Received: [from one.net.au (async9_pool_1.adel.mega.one.net.au [61.12.244.9]) by mail-ob05.one.net.au with ESMTP id f4BEfAa28147; Sat, 12 May 2001 00:41:11 +1000 (EST)] Message-ID: <3AFBFB36.526C4B2A@one.net.au> Date: Sat, 12 May 2001 00:16:14 +0930 From: Rubens X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Cc: freebsd-fs@freebsd.org Subject: Re: Cannot mount logical partitions References: <3AFA9A65.F3CCB40B@one.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (From post to comp.unix.bsd.misc) Hmmm - since I got no answers to that, I changed the kernel and fdisk code to do it, and it looks like it worked. I am including uuencoded versions of both context diffs. (FreeBSD 4.2) begin 644 kernel_patch M26YD97@Z('-Y7,O:V5R;B]S M=6)R7V1I"!E M>'1E;F1E9"!P87)T:71I;VX@*B\*("`C:6YC;'5D92`\7,O;6%L;&]C+F@^"B`@(VEN8VQU9&4@/'-Y M7-L;V7!E(#T]($Q)3E!465!?15A414Y$140@?'P*("`) M"2`@("!S<"T^9'-?='EP92`]/2!$3U-05%E07T585$5.1$5$6"D*("`)"0EM M8G)?97AT96YD960H8G`M/F)?9&5V+"!L<"P@F4@ M/3T@,"D*("`)"0EC;VYT:6YU93L*("`)"6EF("AD<"T^9'!?='EP(#T]($1/ M4U!465!?15A414Y$140@?'P**R`)"0ED<"T^9'!?='EP(#T]($Q)3E!465!? M15A414Y$140@?'P*("`)"2`@("!D<"T^9'!?='EP(#T]($1/4U!465!?15A4 G14Y$1418*2!["B`@"0D)S!X.#,L("),:6YU M>"!F:6QE#@U+"`B3&EN=7@@17AT96YD960@4&%R M=&ET:6]N(GT*("`)+'LP>#DS+"`B06UO96)A(&9I;&5S>7-T96TB?0H@(`DL M>S!X.30L(")!;6]E8F$@8F%D(&)L;V-K('1A8FQE(GT*("`)+'LP>#E&+"`B )0E-$+T]3(GT* ` end Rubens Ramos Fernandes Junior wrote: > > Sorry, I know this has already been discussed but I read heaps of > threads and I still cannot mount my linux ext2 logical partitions > under FreeBSD! > > Under linux (RH6.2), I have: > hdb1 hdb2* > > And I can only mount ad1s1 under FreeBSD 4.2. > I used MAKEDEV to create ad1s3, 4, 5 and 6, > used "options EXT2FS" > and tried to mount /dev/ad1s[3-5] without any success. > > I also tried all sorts of weird stuff, like trying to mount > /dev/ad1s[1-6][a-h]... > > Also removed all options from the linux filesystems using > tune2fs... (sparse_sblocks...) > > I heard people saying they can mount their ext2 logical partitions > in FreeBSD, but how? > > Thanks a lot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri May 11 14:19: 3 2001 Delivered-To: freebsd-fs@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 1E84E37B423; Fri, 11 May 2001 14:19:01 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 11 May 2001 22:19:00 +0100 (BST) To: freebsd-fs@freebsd.org Cc: phk@freebsd.org, iedowse@maths.tcd.ie Subject: Re: vflush() In-Reply-To: Your message of "Wed, 09 May 2001 22:38:39 BST." <200105092238.aa48273@salmon.maths.tcd.ie> Date: Fri, 11 May 2001 22:19:00 +0100 From: Ian Dowse Message-ID: <200105112219.aa94946@salmon.maths.tcd.ie> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200105092238.aa48273@salmon.maths.tcd.ie>, Ian Dowse writes: > >All this suggests that vflush() should subsume the logic for dealing >with the reference count on the filesystem root vnode. This would >simplify the xxx_umount() functions and permits the FORCECLOSE >problem to be solved for all 9 filesystems in one place. A working version of a patch that achieves this is at: http://www.maths.tcd.ie/~iedowse/FreeBSD/vflush_patch As a side-effect, this corrects a vnode leak that currently exists in devfs, as there was a vput() missing for the case where vflush() failed. This bug could result in idle devfs filesystems that refuse to unmount. It seems also, that for future filesystems that may not fit into the simple 'N extra references to the root vnode' model, the situation is not all that bad. These filesystems can simply call vflush with rootrefs==0, and then when it fails check the vnode list to see if any vnodes are really busy. This is no more difficult to deal with than the situation we have now. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri May 11 18:41:10 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 7527637B43E; Fri, 11 May 2001 18:41:06 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 8FE9328C0A; Sat, 12 May 2001 08:40:59 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 82F2128C09; Sat, 12 May 2001 08:40:59 +0700 (ALMST) Date: Sat, 12 May 2001 08:40:59 +0700 (ALMST) From: Boris Popov To: Ian Dowse Cc: freebsd-fs@freebsd.org, phk@freebsd.org Subject: Re: vflush() In-Reply-To: <200105112219.aa94946@salmon.maths.tcd.ie> 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, 11 May 2001, Ian Dowse wrote: > In message <200105092238.aa48273@salmon.maths.tcd.ie>, Ian Dowse writes: > > > >All this suggests that vflush() should subsume the logic for dealing > >with the reference count on the filesystem root vnode. This would > >simplify the xxx_umount() functions and permits the FORCECLOSE > >problem to be solved for all 9 filesystems in one place. > > A working version of a patch that achieves this is at: > > http://www.maths.tcd.ie/~iedowse/FreeBSD/vflush_patch I haven't checked its functionality for each filesystem type, but patch looks good and perfectly centralizes another common part of the code. -- 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 Sat May 12 2:36:11 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id 4CE4C37B423; Sat, 12 May 2001 02:36:03 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 71D0B66C04; Sat, 12 May 2001 02:36:02 -0700 (PDT) Date: Sat, 12 May 2001 02:36:02 -0700 From: Kris Kennaway To: Kirk McKusick Cc: Kris Kennaway , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Ruslan Ermilov , fs@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <20010512023602.A40616@xor.obsecurity.org> References: <20010511121020.B31232@sunbay.com> <200105111916.MAA16255@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105111916.MAA16255@beastie.mckusick.com>; from mckusick@mckusick.com on Fri, May 11, 2001 at 12:16:18PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 11, 2001 at 12:16:18PM -0700, Kirk McKusick wrote: > At the moment there is no provision for notifying the system > administrator since the output of fsck is simply being sent > to the `logger' program (which by default will put the messages > into /var/log/messages). It would be possible to add a syslog > (or wall) call to the fsck program itself. Another alternative > would be to have fsck forcibly downgrade the offending filesystem > to read-only mode. However, if it were say the /var filesystem, > the system would fall apart pretty quickly. I am open to=20 > suggestions on how best to proceed. Working under the assumption that the only time fsck is likely to fail in this manner is if there are FS errors which can't be resolved in the background, and which may result in further FS damage if left uncorrected, the best option seems to be to take some action which prevents this damage. The best series of actions might be the following: 1) Downgrade the FS to readonly mode. 2) syslog(LOG_EMERG, "Unrecoverable error in background check of %s, FS downgraded to readonly mode. Reboot in 60 seconds to attempt to repair the error. Kill PID %d now to abort.", ...) 3) Reboot in 60 seconds This option has a more drastic effect on the system in the short term, but allows the possibility for fsck to correct the error and continue once it comes back up, instead of continuing to operate in a degraded mode (with possible negative impact on the system) until manual operator intervention. Kris --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6/QQBWry0BWjoQKURAlwOAJ9LCCgfUlP6UcJWOSyi/npZKNKF/wCbBoOj +r8KRqCOvg/nU8RaBu+DvZg= =fygn -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat May 12 10:25:21 2001 Delivered-To: freebsd-fs@freebsd.org Received: from dt051n37.san.rr.com (dt051n37.san.rr.com [204.210.32.55]) by hub.freebsd.org (Postfix) with ESMTP id 8D1A737B423; Sat, 12 May 2001 10:25:15 -0700 (PDT) (envelope-from DougB@DougBarton.net) Received: from DougBarton.net (master [10.0.0.2]) by dt051n37.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA61128; Sat, 12 May 2001 10:25:08 -0700 (PDT) (envelope-from DougB@DougBarton.net) Message-ID: <3AFD71F3.905EC08C@DougBarton.net> Date: Sat, 12 May 2001 10:25:07 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Kirk McKusick , fs@FreeBSD.org, current@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] References: <20010511121020.B31232@sunbay.com> <200105111916.MAA16255@beastie.mckusick.com> <20010512023602.A40616@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > > On Fri, May 11, 2001 at 12:16:18PM -0700, Kirk McKusick wrote: > > > At the moment there is no provision for notifying the system > > administrator since the output of fsck is simply being sent > > to the `logger' program (which by default will put the messages > > into /var/log/messages). You can feed 'logger' the -p option with a facility.level pair that will let syslogd decide how to handle it, although I agree that fsck should really use syslog() instead. > > It would be possible to add a syslog > > (or wall) call to the fsck program itself. Another alternative > > would be to have fsck forcibly downgrade the offending filesystem > > to read-only mode. However, if it were say the /var filesystem, > > the system would fall apart pretty quickly. I am open to > > suggestions on how best to proceed. > > Working under the assumption that the only time fsck is likely to fail > in this manner is if there are FS errors which can't be resolved in > the background, and which may result in further FS damage if left > uncorrected, the best option seems to be to take some action which > prevents this damage. > > The best series of actions might be the following: > > 1) Downgrade the FS to readonly mode. This is reasonable, and IMO even more important for an fs like /var that is likely to be written to early in the life of the system. > 2) syslog(LOG_EMERG, "Unrecoverable error in background check of %s, > FS downgraded to readonly mode. Reboot in 60 seconds to attempt to > repair the error. Kill PID %d now to abort.", ...) > > 3) Reboot in 60 seconds I'm not sure that always rebooting is a good idea however. This may be more effort than it's worth, but what about a flag in fstab that indicates something to the effect of, "This partition is essential to the system, reboot automatically to fix it?" For instance, if my /usr/obj partition comes up dirty, I can deal with it by hand, whereas if something important is hosed, I'd like the system to deal with it more drastically. We could default it to on, and let people load the foot-shooting gun themselves if desired. -- I need someone really bad. Are you really bad? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat May 12 23:55: 6 2001 Delivered-To: freebsd-fs@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id BAB5C37B423 for ; Sat, 12 May 2001 23:55:03 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4D6sop05155; Sun, 13 May 2001 08:54:50 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Ian Dowse Cc: freebsd-fs@freebsd.org Subject: Re: vflush() In-Reply-To: Your message of "Fri, 11 May 2001 22:19:00 BST." <200105112219.aa94946@salmon.maths.tcd.ie> Date: Sun, 13 May 2001 08:54:50 +0200 Message-ID: <5153.989736890@critter> From: Poul-Henning Kamp Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200105112219.aa94946@salmon.maths.tcd.ie>, Ian Dowse writes: >In message <200105092238.aa48273@salmon.maths.tcd.ie>, Ian Dowse writes: >> >>All this suggests that vflush() should subsume the logic for dealing >>with the reference count on the filesystem root vnode. This would >>simplify the xxx_umount() functions and permits the FORCECLOSE >>problem to be solved for all 9 filesystems in one place. > >A working version of a patch that achieves this is at: > > http://www.maths.tcd.ie/~iedowse/FreeBSD/vflush_patch Looks good to me. >As a side-effect, this corrects a vnode leak that currently exists >in devfs, as there was a vput() missing for the case where vflush() >failed. This bug could result in idle devfs filesystems that refuse >to unmount. oops... -- 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