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