Well, I have the same problem as well , 2 sata disks and raid1. I tried to do it with two ramdisks and it worked great. when it comes to sata it fails. On 6/13/05, Peter T. Breuer <ptb@xxxxxxxxxxxxxx> wrote: > Diego M. Vadell <dvadell@xxxxxxxxxxxxxx> wrote: > > On Monday 13 June 2005 13:07, Peter T. Breuer wrote: > > > > > I don't know either. For the FR1 code I implemented three new ioctls .. > > > > > all of them sent out by the FR1 (raid1) driver. > > > > > > > > > > 1) notify component that it is in an array and which > > > > > 2) notify component that it is no longer in an array and which > > > > > 3) send component a callback function through which it can > > > > > SET_FAULTY and re-HOTADD itself to the array it kno it is in > > > > > as need be. > > > > > > > > > > Maybe hotplugging has those facilities. I don't know. > > > > > > > > > > Cooperating devices would have to implement the ioctls. > > > > > > > > If I understand right, even if I used FR1, it wont pass the test > > > > > > Yes it will. The device driver will detect something wrong (if the > > > device driver doesn't know, NOBODY does) and call back to the raid array > > > driver to say "set me faulty". > > > > > > That's the whole idea. > > > > > > When the device driver senses its device is well again, it will call > > > back and say "hot add me again". > > > But not as it is today... > > > Yes, "as it is today". > > > when you say "Cooperating devices would have to > > implement the ioctls." means that I have to touch sata_nv's source code to > > implement those ioctls, am I right? > > One has to implement or have implemented those ioctls in the driver of > whichever device you are interested in, in order to cooperate properly > with fr1 (in that respect). That goes without saying. I merely provided > the infrastructure in fr1 - indeed, I could not have provided anything > else because I do not control the code for anything else. Fr1 will send > the ioctls I listed above (or sketched, rather) to any component device. > It is up to that component device to make use of them. > > There may well be another scheme/architecture already available. I > don't know. In my abject ignorance I simply implemented an adequate > scheme for my purposes, and waited for anyone to tell me of a better > one. If hotplugging is supported by the target device, it may well be > the case that you could implement at least ioctl (3) via hotplugging. > > Ioctls (1) and (2) are merely informative. They courteously let the > target device know that it has been included in (or excluded from) a > particular md array. This allows the target device to make any mode > shifts that may be appropriate to running in a raid array, such as > exposing errors immediately to the array instead of blocking and trying > again internally (or vice versa -). It also allows the target device > to decide when or if to make use of the callback function provided to > it in ioctl (3), with which it can tell the raid arrays in which it has > been informed that it has been included of its current state of health. > > > > If that is all I have to do, I will give it a try (supposing my boss does not > > make me use the raid in the motherboard) . > > The enbd code (ftp://oboe.it.uc3m.es/pub/Programs/enbd-2.4.32pre.tgz) > implements the ioctls in question. > > If you know of another scheme, please feel free to tell me about it. > > My idea was that the target device should preemptively inform the array > if it is in good or bad health. This implies that it should know in > which array it is included, in order to know who is interested in > knowing its health. Hence ioctls (1) and (2) which tell it who wishes > to be informed about its health. And ioctl (3) which gives it a > telephone number to use. > > Ioctl (3) could be implemented the other way round - that is, it could > be simply the md array which receives an existing SETFAULTY or HOTADD > ioctl. I don't know why I chose to send across a callback function to > the target device instead. Probably because I was aware of locking > difficulties. > > > Peter > > - > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Raz Long Live the Penguin - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
