Greg 'groggy' Lehey wrote:
On Tuesday, 30 March 2004 at 14:37:00 +0200, Lukas Ertl wrote:
On Fri, 26 Mar 2004, Joao Carlos Mendes Luis wrote:
I think this should be like:
if (plex->state > plex_corrupt) { /* something accessible, */
Or, in other words, volume state is up only if plex state is degraded or better.
You are right, this is a bug,
No, see my reply.
I think "maybe" is the best answer here.
The correct solution, of course, is to check if the data is valid before changing the volume state, but turn might turn out to be a very complex check.
Well, the minimum correct solution is to return an error if somebody tries to access the inaccessible part of the volume. That should happen, and I'm confused that it doesn't appear to be doing so in this case.
On Tuesday, 30 March 2004 at 11:07:55 -0300, Joo Carlos Mendes Lus wrote:
Greg 'groggy' Lehey wrote:
On Tuesday, 30 March 2004 at 0:32:38 -0300, Joo Carlos Mendes Lus wrote:
Basically, this is a feature and not a bug. A plex that is corrupt is still partially accessible, so we should allow access to it. If you have two striped plexes both striped between two disks, with the same stripe size, and one plex starts on the first drive, and the other on the second, and one drive dies, then each plex will lose half of its data, every second stripe. But the volume will be completely accessible.
A good idea if you have both stripe and mirror, to avoid discarding the whole disk. But, IMHO, if some part of the disk is inacessible, the volume should go down, and IFF the operator wants to try recovery, should use the setstate command. This is the safe state.
setstate is not safe. It bypasses a lot of consistency checking.
That's why it should be done only by a human operator, and only after checking the physical disk. I use setstate frequently, when I have my wizard hat on, but I know the consequences of doing that. If I have someone watching I carefully explain then to *not* repeat that. ;-)
One possibility would be:
1. Based on the plex states, check if all of the volume is still
accessible.
2. If not, take the volume into a "flaky" state.
This is easy if the volume is composed of a single plex (my case, and the case of most people who needs only a big and "unsafe" disk. Where unsafe means a disk available or not available, and not half a disk. At least for me.
If the volume has more than one plex, then you could think of an algoritm that explores this redundancy.
But, IMO, a disk with half of it unavailable is hardly an "up and ok" one.
Also note that, instead of turning the whole subdisk stale when a single I/O fails, the error could be passed above. But, also, this only works with single plex stripe or concat configurations.
3. *Somehow* ensure that the volume can't be accessed again as a file system until it has been remounted. 4. Refuse to remount the file system without the -f option.
The last two are outside the scope of Vinum, of course.
And again violates the layering aproach. I thought newfs -v has been enough...
The first time I used vinum I was happilly thinking that I would mix 4 whole disks (except for boot and swap partitions, of course) and create a new pseudo disk, in which I would again disklabel it, and repartition for expected use. Say, for example, that I want to have /var and /usr on different partitions, but I want both with mirroring. With real world vinum I need to create 2 vinum partitions on real disks, and have 2 vinum volumes.
AFAIK, -current and GEOM fixes this, right? My last experience with RaidFrame was a panic one, since the disk creation. But I must confess I did not try that hard, since vinum and -stable was working for me. I am not a -current hacker for a long time now.
Greg, I like vinum, and I use it since its release in FreeBSD. Before that I have used ccd(4). When 5.x is stable, I will use GEOM, vinum or raidframe. But I really think *ix is great for it's reusability, recursivity and modularity and vinum breaks this. If vinum creates a virtual disk, it should behave like a real disk.
Jonny
-- Jo�o Carlos Mendes Lu�s - Networking Engineer - [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
