Re[2]: ffs_alloc panic patch

• Previous message: Pavel Merdine: "Re[2]: ffs_alloc panic patch"
• In reply to: Ken Smith: "Re: ffs_alloc panic patch"
• Next in thread: Pavel Merdine: "Re[2]: ffs_alloc panic patch"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 28 Aug 2004 12:51:44 +0400
To: Ken Smith <freebsd-stable@freebsd.org>

Hello ,

I think that umount should be the last resort.
For example, we are going to write a file. This fails at the bottom of
the code. Why can we just report that we failed to write it? For
example if we didn't change any internal structures? I'm sure we can
still read from that disk. (I hope there are no panics in read code?)

Saturday, August 28, 2004, 12:42:17 AM, you wrote:

> On Fri, Aug 27, 2004 at 12:55:39PM -0700, Colin Percival wrote:
>> At 12:36 27/08/2004, Ken Smith wrote:
>> > ... Here you again wind up in a
>> > situation where the filesystem data structures on the disk can
>> > become corrupted. Typically at some point the ffs code will
>> > recognize that the metadata is incorrect and again a panic is
>> > better than trying to carry on pretending nothing is wrong.
>>
>> Shouldn't a corrupt filesystem be handled by forcibly dismounting it,
>> rather than invoking panic()? We certainly don't want to keep on using
>> a corrupt filesystem, but we should attempt to isolate a single failing
>> piece of hardware rather than allowing it to bring down the entire
>> system.

> It's too hard to decide whether the filesystem in question can be lived
> without. Certainly / can't be lived without. The contents of /var
> can't be lived without, it may or may not be on a separate filesystem.
> Suppose I chose to have /tmp on a separate filesystem and we actually
> did manage to successfully unmount it (hee hee hee :-), typically
> the directory permissions of the /tmp directory as represented in the
> root filesystem itself are wrong (setting it to be rwxrwxrwt was done
> after it had been mounted and it's the permissions from the mounted
> filesystem that are normally seen). Can we live without /usr? Did
> we set up cron jobs that will do really really really nasty things if
> the filesystem doesn't look the way it should because something got
> unmounted we weren't expecting? Suppose we're running a mirror site
> with a large repository in /ftp, it fails, but the machine remains
> up and running - downstream mirror sites connect, see nothing, and
> dutifully remove everything on their site.

> Too many decisions the kernel shouldn't make... :-)

> The isolating a single failing piece of hardware thing is RAID turf.

-- 
/ Pavel Merdine
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

• Previous message: Pavel Merdine: "Re[2]: ffs_alloc panic patch"
• In reply to: Ken Smith: "Re: ffs_alloc panic patch"
• Next in thread: Pavel Merdine: "Re[2]: ffs_alloc panic patch"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]