From owner-freebsd-hackers Mon Mar 20 14:24:36 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA09853 for hackers-outgoing; Mon, 20 Mar 1995 14:24:36 -0800 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id OAA09844 for ; Mon, 20 Mar 1995 14:24:31 -0800 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <26420-0@bunyip.cc.uq.oz.au>; Tue, 21 Mar 1995 07:57:04 +1000 Received: from orion.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id TAA00318 for ; Mon, 20 Mar 1995 19:30:19 +1000 Received: by orion.devetir.qld.gov.au (8.6.10/DEVETIR-0.2a) id TAA15395; Mon, 20 Mar 1995 19:27:18 +1000 Date: Mon, 20 Mar 1995 19:27:18 +1000 From: Stephen McKay Message-Id: <199503200927.TAA15395@orion.devetir.qld.gov.au> To: hackers@FreeBSD.org cc: syssgm@devetir.qld.gov.au Subject: Re: Filesystem clean flag Sender: hackers-owner@FreeBSD.org Precedence: bulk David Greenman writes; >>> As David Greenman wrote: >>> > The system should not allow mounting a dirty filesystem writable. >>> >>> But then, there should also be a way to get around this. The super >>> user is assumed to know what he's doing -- and be it for the only >>> reason to save just one [apparently good] file out of a totally >>> damaged disk before newfs'ing it. >> >>Why would he need to mount it writeable for that ? > > Yes, this is why I said "writable" above. I would always want read-only to >work. ...but like I just said in a previous message, an option to force the >system to mount writable it wouldn't be unreasonable. If you don't provide this option, I'll just have to add it. Certainly a restriction on mounting dirty broken filesystems read/write would hamper my current attempt to reconstruct my severly damaged filesystems. It wouldn't make it impossible, just that bit more painful. Perhaps some weeks ago I would have agreed that writing to broken filesystems was pointless, but now that I'm up to my armpits in it, its just as handy as writing to healthy filesystems. The principle that (with suitable flags) root jolly well knows exactly what he/she is doing should be upheld until the bitter end. BTW, does anyone have any disk-cruising/filesystem-fixing programs that are friendlier than fsck? My 1.1 system went mad and overwrote every root directory and their superblocks and a good number of other (apparently) random blocks. I think I upset my tape drive while reading past EOD... Stephen.