volume management
Eric Anderson
anderson at freebsd.org
Tue Apr 10 17:55:23 UTC 2007
On 04/10/07 12:46, Gergely CZUCZY wrote:
> On Tue, Apr 10, 2007 at 12:42:29PM -0500, Eric Anderson wrote:
>>>> It will be
>>>> great to just fix everything in the kernel to handle errors properly,
>>>> but good luck with that.
>>> That's a worthy goal and something we should be pursuing. After all,
>>> FreeBSD used to be noted for its stability. I wouldn't call panics a sign
>>> of stability.. You're better off invalidating all the geom consumers and
>>> leaving the rest of the system up so an admin can try to recover critical
>>> data, or so the remaining geom providers can continue to function.
>> There's been talk in the past about making the mount read-only instead of a panic in some
>> situations, but I know nothing more than that.
> I quite like this idea, but what about updates? I don't know
> whether updates require additional space for UFS2 or not, but
> I can imagine the opportunity when updates can be done while
> there is no more space for allocating new blocks.
I think the only time this might even be an option is under very minimal
conditions. As Pawel said, if your FS is corrupt, you'll get hosed down
the line.
Personally, what I would want to prevent, is having a server go down due
to one file system having an issue, when it is serving (or using) many
more file systems. I currently have a box with 5 10Tb file systems on
it, and when I mount a 6th file system (2Tb) which I *know* has metadata
inconsistencies that fsck can't fix, I don't want it to take down all
50Tb of good solid storage. What I want is a blast to my logs, the
erroneous file system to be evicted from further damage (mount read-only
and marked as dirty) and trickle an i/o error to any processes trying to
write to it. Even unmounting it would be ok, but that gets nasty with
NFS servers and other things.
Eric
More information about the freebsd-geom
mailing list