[linux-lvm] raid 1 on a single disk

[linux-lvm] raid 1 on a single disk

[ashwin chaugule]

Hi,
         Im trying to get RAID 1 working on a single disk. Can anyone
tell me if thats possible ?
Do I have to use LVM for that ?

So, far this is what i've understood ...
Now.. I have a separate disk on which I want RAID 1.
so I create one PV on that disk (/dev/hdd)
create a logical vol grp.
add 4 LV's , for four filesystems of the same type ...
then in /etc/raidtab or whatever ..
say that i have 4 disks and for each disk specify each LV partition ..
then mkraid /dev/md0 ...

Is this correct if I want data to be mirrored across all 4 partitions
, using RAID 1 on a single disk ?



-- 
Ashwin Chaugule
Embedded Systems Engineer
Aftek Infosys ltd.
[Embedded Division]

[linux-lvm] Re: raid 1 on a single disk

[Peter T. Breuer]

ashwin chaugule <ashwin.chaugule@gmail.com> wrote:
>          Im trying to get RAID 1 working on a single disk. Can anyone
> tell me if thats possible ?

Yes, of course it is.

> Do I have to use LVM for that ?

No.

> So, far this is what i've understood ...
> Now.. I have a separate disk on which I want RAID 1.
> so I create one PV on that disk (/dev/hdd)

No you don't. LVM is not involved.

> create a logical vol grp.


No you don't. LVM is not involved.


> add 4 LV's , for four filesystems of the same type ...

No you don't. LVM is not involved.

> then in /etc/raidtab or whatever ..
> say that i have 4 disks and for each disk specify each LV partition ..

No you don't, since LVM is not involved.

> then mkraid /dev/md0 ...
> 
> Is this correct if I want data to be mirrored across all 4 partitions
> , using RAID 1 on a single disk ?

So, you are talking about a mirror with 4 components, all of them
partitions on the same disk?

Well, that's silly, but nothing stops you doing it. Just maek a raidtab
for the mirror and name the partitions as raid-disk components there.
The RAID howto or faq should tell you all you need to know, as should
the mananpage for the conf file or mdadm, or whatever ...

Peter

Re: [linux-lvm] Re: raid 1 on a single disk

[ashwin chaugule]

yes i know its silly ... im doing what im told to do :p

ok so, i also do know, its performance is going to suck !
but i was under the impression that RAID 1 works on more that one disks only.

so you mean to say that, the linux RAID / md tools support raid 1 on
multiple partitiions of the same disk ?

Regards,
Ashwin
 



On Sat, 13 Nov 2004 11:33:25 +0100, Peter T. Breuer <ptb@lab.it.uc3m.es> wrote:
> ashwin chaugule <ashwin.chaugule@gmail.com> wrote:
> >          Im trying to get RAID 1 working on a single disk. Can anyone
> > tell me if thats possible ?
> 
> Yes, of course it is.
> 
> > Do I have to use LVM for that ?
> 
> No.
> 
> > So, far this is what i've understood ...
> > Now.. I have a separate disk on which I want RAID 1.
> > so I create one PV on that disk (/dev/hdd)
> 
> No you don't. LVM is not involved.
> 
> > create a logical vol grp.
> 
> 
> No you don't. LVM is not involved.
> 
> 
> > add 4 LV's , for four filesystems of the same type ...
> 
> No you don't. LVM is not involved.
> 
> > then in /etc/raidtab or whatever ..
> > say that i have 4 disks and for each disk specify each LV partition ..
> 
> No you don't, since LVM is not involved.
> 
> > then mkraid /dev/md0 ...
> >
> > Is this correct if I want data to be mirrored across all 4 partitions
> > , using RAID 1 on a single disk ?
> 
> So, you are talking about a mirror with 4 components, all of them
> partitions on the same disk?
> 
> Well, that's silly, but nothing stops you doing it. Just maek a raidtab
> for the mirror and name the partitions as raid-disk components there.
> The RAID howto or faq should tell you all you need to know, as should
> the mananpage for the conf file or mdadm, or whatever ...
> 
> Peter
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 


-- 
Ashwin Chaugule
Embedded Systems Engineer
Aftek Infosys ltd.
[Embedded Division]

Re: [linux-lvm] Re: raid 1 on a single disk

[Piete Brooks]

> yes i know its silly ... im doing what im told to do :p

Don't.

Part of your job is to try to work out what they *meant* to tell you.

Explain what they are asking you to do (I've not yet grasped it), explain the 
problems with it (e.g. if the disk fails, all is lost), and offer suggestions 
as to what they might have wanted.

> ok so, i also do know, its performance is going to suck !

Yes.

And what's the point?
It will protect against a single bad block, but not a disc failure.

> but i was under the impression that RAID 1 works on more that one disks only.

RAID doesn't know about discs (much -- it does try not to RESYNC multiple 
partitions on a single disc at once, as it causes head thrashing) -- it just 
deals in partitions. It doesn't care where they are.

But regardless of that, RAID1 is quite happy to run using a single partition

	mdadm -C -l1 -n2 /dev/md1 /dev/hda1 missing

> so you mean to say that, the linux RAID / md tools support raid 1 on
> multiple partitiions of the same disk ?

It doesn't care!

[linux-lvm] Re: raid 1 on a single disk

[Peter T. Breuer]

ashwin chaugule <ashwin.chaugule@gmail.com> wrote:

(please do not top post - fixing. Please take note!)

> > > Is this correct if I want data to be mirrored across all 4 partitions
> > > , using RAID 1 on a single disk ?
> > 
> > So, you are talking about a mirror with 4 components, all of them
> > partitions on the same disk?
> > 
> > Well, that's silly, but nothing stops you doing it. Just maek a raidtab
> > for the mirror and name the partitions as raid-disk components there.
> > The RAID howto or faq should tell you all you need to know, as should
> > the mananpage for the conf file or mdadm, or whatever ...

> ok so, i also do know, its performance is going to suck !

No, it'll be fine - merely a couple or more times slower at writing
large streams. In ordinary use you may sometimes see more latency, but 
provided you aren't streaming or running synchronous writes, you
shouldn't notice. What's silly is that there's no point in doing it -
you get no protection against the disk disappearing, because all the
mirror components are on the same disk.

It's like making 3 sets of spare housekeys, and then putting them all
in the same keyholder as the original set, and walking around like that.

Silly, no?

> but i was under the impression that RAID 1 works on more that one disks only.

I don't understand you. While a mirror with only one component is
trivial, it is a mirror.

> so you mean to say that, the linux RAID / md tools support raid 1 on
> multiple partitiions of the same disk ?

Nobody cares where the mirror components are physically sited except
you.  Why should any tool care?  Its job is to do what you say.  I don't
understand why you should think that the tool would even know (well,
there is a chance that it could look and check, but I don't recall any
significant code in the driver dedicated to optimizations based on that).

Peter

Re: [linux-lvm] Re: raid 1 on a single disk

[Piete Brooks]

> (please do not top post - fixing. Please take note!)
(what's "top post"ing?)

>> ok so, i also do know, its performance is going to suck ! 
> No, it'll be fine - merely a couple or more times slower at writing
> large streams.

Actually, over 4 times :-(

He has a 4 way mirror on hdd.
As well as having to send all date over the (same!) IDE bus 4 times,
the disk head keeps having to move between the 4 partitions :-(

> What's silly is that there's no point in doing it

Not true -- there is little point.

It will protect against un-re-vectored block faults.

> you get no protection against the disk disappearing

Indeed -- which is the real use for RAID1 ...

> It's like making 3 sets of spare housekeys, and then putting them all
> in the same keyholder as the original set, and walking around like that.

Which has *some* use if the keys are made of very soft metal and "wear out".

[ His actual problem was that he didn't realise that mkraid is brain dead, and 
needs a chunk size in /etc/raidtab, even when it's not used!  I showed him how 
to use mdadm, and it worked ]

[linux-lvm] Re: raid 1 on a single disk

[Peter T. Breuer]

Piete Brooks <Piete.Brooks@cl.cam.ac.uk> wrote:
> > (please do not top post - fixing. Please take note!)
> (what's "top post"ing?)

The opposite of bottom posting, neither of which being apposite, let us
skip over the discussion of.

> >> ok so, i also do know, its performance is going to suck ! 
> > No, it'll be fine - merely a couple or more times slower at writing
> > large streams.
> 
> Actually, over 4 times :-(

Hi Piete! It's getting on for 20 years since you wrote me a ptty
straight off, without looking anything up, while sitting at the console
in the lab in cam. No - it won't be. He's just writing to memory in
general and he'll get the ack as fast as he usually does from that.
True, the writes will take longer to complete their whole journey to
disk, but that's way after he's gone home and had supper.  He talks to
buffers in the VMS, not the driver.

> He has a 4 way mirror on hdd.
> As well as having to send all date over the (same!) IDE bus 4 times,
> the disk head keeps having to move between the 4 partitions :-(

Yeah, I know. But he won't notice, so long as he uses the device
"normally". As soon as he starts streaming to it and placing it under
write pressure, and memory fills up and the VMS goes sync (see
bdflush settings), THEN he'll notice, but not in normal use, if what is
normal is what I think it is. Writes are async to the user.

> > What's silly is that there's no point in doing it
> 
> Not true -- there is little point.
> 
> It will protect against un-re-vectored block faults.

Yes, if his disk doesn't swap them in automatically on write (or he
runs out of spares and it does). On read I'm not sure what will happen.
I suppose he'll get a crc error and a fail from the read attempt, and
then the partition will fault out of the array, and with luck the
driver will retry on another partition. But I'm not sure from memory
of the code if it DOES the retry. Common sense wuld say that the code
for that has to be there, but I don't recall it.


> > you get no protection against the disk disappearing
> 
> Indeed -- which is the real use for RAID1 ...
> 
> > It's like making 3 sets of spare housekeys, and then putting them all
> > in the same keyholder as the original set, and walking around like that.
> 
> Which has *some* use if the keys are made of very soft metal and "wear out".

:-). Unfortunately he insists on using ALL the keys every time, out of
a sense of completeness, so they ALL wear at the same rate.

He can win only on read, which is faster if he is lucky or does it right
(uh, he won't - he only wins if he can do two reads at once, and he
can't, since it's all the same disk) and may be less wearing. Yes, it
is less wearing on read, since the frequency of reading any particular
part of the disk is only 1/4 of what it normally would be.

> [ His actual problem was that he didn't realise that mkraid is brain dead, and 
> needs a chunk size in /etc/raidtab, even when it's not used!  I showed him how 
> to use mdadm, and it worked ]

Good! Yes, I think I recall that.  Thanks very much for your
intercession :-).


Peter

Re: [linux-lvm] Re: raid 1 on a single disk

[ashwin chaugule]

read my earlier mails ... 
it is silly , but not as silly as trying to modify the kernel code for
just one specific disk : )




On Sat, 13 Nov 2004 13:59:19 +0100, Peter T. Breuer <ptb@lab.it.uc3m.es> wrote:
> ashwin chaugule <ashwin.chaugule@gmail.com> wrote:
> 
> (please do not top post - fixing. Please take note!)
> 
> 
> 
> > > > Is this correct if I want data to be mirrored across all 4 partitions
> > > > , using RAID 1 on a single disk ?
> > >
> > > So, you are talking about a mirror with 4 components, all of them
> > > partitions on the same disk?
> > >
> > > Well, that's silly, but nothing stops you doing it. Just maek a raidtab
> > > for the mirror and name the partitions as raid-disk components there.
> > > The RAID howto or faq should tell you all you need to know, as should
> > > the mananpage for the conf file or mdadm, or whatever ...
> 
> > ok so, i also do know, its performance is going to suck !
> 
> No, it'll be fine - merely a couple or more times slower at writing
> large streams. In ordinary use you may sometimes see more latency, but
> provided you aren't streaming or running synchronous writes, you
> shouldn't notice. What's silly is that there's no point in doing it -
> you get no protection against the disk disappearing, because all the
> mirror components are on the same disk.
> 
> It's like making 3 sets of spare housekeys, and then putting them all
> in the same keyholder as the original set, and walking around like that.
> 
> Silly, no?
> 
> > but i was under the impression that RAID 1 works on more that one disks only.
> 
> I don't understand you. While a mirror with only one component is
> trivial, it is a mirror.
> 
> > so you mean to say that, the linux RAID / md tools support raid 1 on
> > multiple partitiions of the same disk ?
> 
> Nobody cares where the mirror components are physically sited except
> you.  Why should any tool care?  Its job is to do what you say.  I don't
> understand why you should think that the tool would even know (well,
> there is a chance that it could look and check, but I don't recall any
> significant code in the driver dedicated to optimizations based on that).
> 
> 
> 
> Peter
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 


-- 
Ashwin Chaugule
Embedded Systems Engineer
Aftek Infosys ltd.
[Embedded Division]

Re: [linux-lvm] Re: raid 1 on a single disk

[Graham Wood]

On Sat, Nov 13, 2004 at 04:11:08PM +0530, ashwin chaugule wrote:
> yes i know its silly ... im doing what im told to do :p
>
> ok so, i also do know, its performance is going to suck !
> but i was under the impression that RAID 1 works on more that one disks only.
>
> so you mean to say that, the linux RAID / md tools support raid 1 on
> multiple partitiions of the same disk ?
>
> Regards,
> Ashwin
>
>

As people have already said, the software really doesn't care.

Here's a really sick/pointless example to prove it:

dd if=/dev/zero of=/var/tmp/fake1 bs=1M count=16
dd if=/dev/zero of=/var/tmp/fake2 bs=1M count=16
dd if=/dev/zero of=/var/tmp/fake3 bs=1M count=16
dd if=/dev/zero of=/var/tmp/fake4 bs=1M count=16

losetup /dev/loop1 /var/tmp/fake1
losetup /dev/loop2 /var/tmp/fake2
losetup /dev/loop3 /var/tmp/fake3
losetup /dev/loop4 /var/tmp/fake4

mdadm --create -l 5 /dev/md10 -n 4 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4

cat /proc/mdstat

md10 : active raid5 loop4[4] loop3[2] loop2[1] loop1[0]
      48960 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_]
      [================>....]  recovery = 81.2% (14080/16320) finish=0.0min speed=1083K/sec

raidstop -c /dev/null /dev/md10

mdadm --create -l mirror  /dev/md10 -n 4 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4

cat /proc/mdstat

md10 : active raid1 loop4[3] loop3[2] loop2[1] loop1[0]
      16320 blocks [4/4] [UUUU]
      [=============>.......]  resync = 68.7% (12160/16320) finish=0.0min speed=1105K/sec


What this has done is created a 48MB (roughly) raid5 set based on 4 16MB files in /var/tmp.  Obviously this won't be recreated automatically on a reboot (since it's done using files), but it's to show what you can do if you are feeling sick enough.  I've then created it as a mirror to show that works too.

Your command (to setup the mirror) will be something like:

mdadm --create -l mirror -n 4 /dev/hdd1 /dev/hdd2 /dev/hdd3 /dev/hdd4

And since thoswe are real disk partitions, if you set them to type "fd" in fdisk, they will be re-attached on a reboot.

Graham

P.S. I'd be really tempted to talk to the person asking you to do this, and ask them what they hope to achieve...

Re: [linux-lvm] Re: raid 1 on a single disk

[Greg Freemyer]

> 
> P.S. I'd be really tempted to talk to the person asking you to do this, and ask them what they hope to achieve...
> 
I can almost envision times it would be useful.  i.e. disk speed is
unimportand, disk data rarely changes, but when it does it is very
important, and traditional backups are not feasible for some unknown
reason?

By having the data written to 2 different places on the disk, the
likelyhood of a failure making it  truly unrecoverable is extremely
small.

ie. If you have disk media problems, likely only one location of the
other will be affected.

If you have a drive electronics failure, you can ship the drive off to
have recovery performed.  (Over $1000 I know, but if the data is
important.)

Greg

[linux-lvm] Re: raid 1 on a single disk

[Måns Rullgård]

Greg Freemyer <greg.freemyer@gmail.com> writes:

>> 
>> P.S. I'd be really tempted to talk to the person asking you to do
>> this, and ask them what they hope to achieve...
>> 
> I can almost envision times it would be useful.  i.e. disk speed is
> unimportand, disk data rarely changes, but when it does it is very
> important, and traditional backups are not feasible for some unknown
> reason?
>
> By having the data written to 2 different places on the disk, the
> likelyhood of a failure making it  truly unrecoverable is extremely
> small.

Shall I tell you about the 80GB disk I had that suddenly dropped dead,
refusing all form of communication?

> ie. If you have disk media problems, likely only one location of the
> other will be affected.
>
> If you have a drive electronics failure, you can ship the drive off to
> have recovery performed.  (Over $1000 I know, but if the data is
> important.)

I'd rather pay the $100 for a mirror disk, which is also what I do in
my systems, after the lesson learned from the aforementioned failure.
I got four new disks, and configured them as RAID5.  Within a month,
one of them failed.

-- 
M�ns Rullg�rd
mru@inprovide.com

Re: [linux-lvm] Re: raid 1 on a single disk

[ashwin chaugule]

There Greg ! , you got it right !
The media onto which the data will be stored is a small device, that
functions like a hdd,
this endeavour was just for a proof of concept.

I've also managed to hack into the kernel IDE susbsys. (ide-disk.c) to
duplicate the writes and reads for this particular disk.

So now I have two options for them.

RAID 1 is useful here (although its on one disk) because , data will
not be written / read _very_ often to/from the device. And in the
event that the media is flaky, will provide like a backup. The other
benefit is, I dont have to worry about the i/o errors (or any other
for that matter) while reading the contents back, the best copy
*should* be picked up by the md subsys itself.

However, in my driver (modified IDE) I have to take care of the writes
and reads individualy.
The advantage here is that, i dont need to make 4 partitions of the
disk, one is good enough, and the remaining can be unallocated. I make
the write at fixed offsets into the unallocated space, and when read
is requested, I read em one by one, and check.

So, there.


On Sat, 13 Nov 2004 17:00:35 -0500, Greg Freemyer
<greg.freemyer@gmail.com> wrote:
> >
> > P.S. I'd be really tempted to talk to the person asking you to do this, and ask them what they hope to achieve...
> > 
> I can almost envision times it would be useful.  i.e. disk speed is
> unimportand, disk data rarely changes, but when it does it is very
> important, and traditional backups are not feasible for some unknown
> reason?
> 
> By having the data written to 2 different places on the disk, the
> likelyhood of a failure making it  truly unrecoverable is extremely
> small.
> 
> ie. If you have disk media problems, likely only one location of the
> other will be affected.
> 
> If you have a drive electronics failure, you can ship the drive off to
> have recovery performed.  (Over $1000 I know, but if the data is
> important.)
> 
> Greg
> 
> _______________________________________________
> 
> 
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 


-- 
Ashwin Chaugule
Embedded Systems Engineer
Aftek Infosys ltd.
[Embedded Division]

[linux-lvm] Re: raid 1 on a single disk

[Peter T. Breuer]

ashwin chaugule <ashwin.chaugule@gmail.com> wrote:
> I've also managed to hack into the kernel IDE susbsys. (ide-disk.c) to
> duplicate the writes and reads for this particular disk.

It's extremely unlikely you got this right. Recall that the driver has
to work when out of memory, and that if you generate another write
request like the request you received, then you will need another
request struct and another bh struct for each one in the original. You
also have to point them at the buffers in the original request, and
make sue that the original request's end_bh (end_bio :) functions do
not free the original buffers, but wait till your extra request has
completed too. Those structs take memory, and have to come from
somewhere.

In other words, you have to do what the raid1 driver does. Maintain a
local pool.

Note that the raid1 driver chooses to be synchronous on write, that is
not ack your original request until all the copies have finished. It
has to do that because it can't mark sections of the target as out of
date on disk, so it has to complete all writes while the knowledge
that it has to is still in memory. It can't pick up later and complete
them. You may wish to improve that (the FR1 driver, mine, at
fr1.sf.net, can also go async on write if you want it to).

> RAID 1 is useful here (although its on one disk) because , data will
> not be written / read _very_ often to/from the device. And in the
> event that the media is flaky, will provide like a backup. The other

Provided that you know WHICH of the copies is right :-).

> benefit is, I dont have to worry about the i/o errors (or any other
> for that matter) while reading the contents back, the best copy
> *should* be picked up by the md subsys itself.

Best? 

Peter

Re: [linux-lvm] Re: raid 1 on a single disk

[ashwin chaugule]

ok , here is what ive done ...

for my particular disk : when there's a write request, I duplicate the
req struct first(using kmalloc ), call a function to put in custom
values into the respective registers ( LBA format) using 'block' .
Then I set the interupt handler to a custom routine, where it will put
the correct desired LBA addr into the IDE_DATA_REG ( by calling
ata_output_data) ... after which without calling end_request i let the
_original_ request struct do its thing , by calling the default
interrupt handler which later calls an end_request.

That way , on one knows(or atleast i hope)  that i've performed a
duplicate write. Ive verified this, the file gets duplicated.

BUT ! for some unknown reason, when I unmount the partition , it hangs ! 

Why would this be happening ? Why should the filesystem be affected,
if it doesnt even know that i've performed a duplicate write !

Im still working on the read requests...



On Sun, 14 Nov 2004 12:28:32 +0100, Peter T. Breuer <ptb@lab.it.uc3m.es> wrote:
> ashwin chaugule <ashwin.chaugule@gmail.com> wrote:
> > I've also managed to hack into the kernel IDE susbsys. (ide-disk.c) to
> > duplicate the writes and reads for this particular disk.
> 
> It's extremely unlikely you got this right. Recall that the driver has
> to work when out of memory, and that if you generate another write
> request like the request you received, then you will need another
> request struct and another bh struct for each one in the original. You
> also have to point them at the buffers in the original request, and
> make sue that the original request's end_bh (end_bio :) functions do
> not free the original buffers, but wait till your extra request has
> completed too. Those structs take memory, and have to come from
> somewhere.
> 
> In other words, you have to do what the raid1 driver does. Maintain a
> local pool.
> 
> Note that the raid1 driver chooses to be synchronous on write, that is
> not ack your original request until all the copies have finished. It
> has to do that because it can't mark sections of the target as out of
> date on disk, so it has to complete all writes while the knowledge
> that it has to is still in memory. It can't pick up later and complete
> them. You may wish to improve that (the FR1 driver, mine, at
> fr1.sf.net, can also go async on write if you want it to).
> 
> > RAID 1 is useful here (although its on one disk) because , data will
> > not be written / read _very_ often to/from the device. And in the
> > event that the media is flaky, will provide like a backup. The other
> 
> Provided that you know WHICH of the copies is right :-).
> 
> > benefit is, I dont have to worry about the i/o errors (or any other
> > for that matter) while reading the contents back, the best copy
> > *should* be picked up by the md subsys itself.
> 
> Best?
> 
> Peter
> 
> _______________________________________________
> 
> 
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> 


-- 
Ashwin Chaugule
Embedded Systems Engineer
Aftek Infosys ltd.
[Embedded Division]

[linux-lvm] Re: raid 1 on a single disk

[Peter T. Breuer]

ashwin chaugule <ashwin.chaugule@gmail.com> wrote:
> ok , here is what ive done ...

How about you ceasing top posting in favour of posting comprehensibly.
I've asked several times, no? It's extremely irritating - I'll do my
best to fix this post, again ... (it takes work!)
 
> On Sun, 14 Nov 2004 12:28:32 +0100, Peter T. Breuer <ptb@lab.it.uc3m.es> wrote:
> > ashwin chaugule <ashwin.chaugule@gmail.com> wrote:
> > > I've also managed to hack into the kernel IDE susbsys. (ide-disk.c) to
> > > duplicate the writes and reads for this particular disk.
> > 
> > It's extremely unlikely you got this right. Recall that the driver has
> > to work when out of memory, and that if you generate another write
> > request like the request you received, then you will need another
> > request struct and another bh struct for each one in the original. You
> > also have to point them at the buffers in the original request, and
> > make sue that the original request's end_bh (end_bio :) functions do
> > not free the original buffers, but wait till your extra request has
> > completed too. Those structs take memory, and have to come from
> > somewhere.

> for my particular disk : when there's a write request, I duplicate the
> req struct first(using kmalloc ),

Request structs come from a kernel pool. You make them by simply
submitting buffer heads to the kernel (submit_bh, make_request, etc.).
The kernel will aggregate buffer heads submitted as it thinks fit into
request structures, which it will send to the appropriate device queue.

You should not be making your own request struct, because it may
accidently be grabbed by the kernel mechanisms that assemble and
disassemble these, and then There Will Be Tears.


> call a function to put in custom
> values into the respective registers ( LBA format) using 'block' .

Registers?  What registers? Do you mean "fields"?

> Then I set the interupt handler to a custom routine, where it will put
> the correct desired LBA addr into the IDE_DATA_REG ( by calling
> ata_output_data) ...

This sounds like stuff you do in the driver , on receipt of your special
request.  Is that so and how do you recognize it

> after which without calling end_request i let the
> _original_ request struct do its thing , by calling the default
> interrupt handler which later calls an end_request.

Default interrupt handler? What? Are you talking about end_io? Your
driver will call end_request on a request (which will call end_io
on its buffer heads) when it thinks the request has been handled by the
device.



> That way , on one knows(or atleast i hope)  that i've performed a
> duplicate write. Ive verified this, the file gets duplicated.

It sounds to me that when you receive a request at very low level in
the driver, you change certain offsets that affect the handling of the
request, then change them back, and that way catch the original request
too. I am unclear as to whether you duplicate requests and submit them
twice to the driver queue, or whether you only have one request hit the
driver and when it hits you simply treat it twice, having
copied its structure for safety. I think the latter.

How do you get the requests to the driver, ensure that treatment of
your clones occurs when you think it does, etc?

> BUT ! for some unknown reason, when I unmount the partition , it hangs ! 

Probably because some stuff is returned to kernel pools and messes them
up completely.

> Why would this be happening ? Why should the filesystem be affected,

Because your code, like your description, is an uncontrolled mess,
probably.

> if it doesnt even know that i've performed a duplicate write !

Nobody knows anything.

Puhleeeeze. Please just use raid.



Peter

Re: [linux-lvm] Re: raid 1 on a single disk

[ashwin chaugule]

>Because your code, like your description, is an uncontrolled mess,
>probably.

WHAT !!!!!

>Registers?  What registers? Do you mean "fields"?

yes i mean fields, my bad.


>This sounds like stuff you do in the driver , on receipt of your special
>request.  Is that so and how do you recognize it

by checking the MAJOR and MINOR num of my disk !!!!! ?

>Default interrupt handler? 

remember i said , i set a different intr. handler if its my disk !? 
well, after its handled there, i dont call end_request , simple.
eg.
mult_write is the default intr. handler for multiple writes ?
i set mult_write_withoutend as the handler, then after the handling is
done , i again set
mult_write as the handler.... this will call the end_request.

>or whether you only have one request hit the
>driver and when it hits you simply treat it twice

bingo !

>Probably because some stuff is returned to kernel pools and messes them
>up completely.

what stuff ? im not returning anything to any queue whatsoever !

>Because your code, like your description, is an uncontrolled mess,
>probably.

about the code .. umm , maybe not , coz the write is duplicated alright ..
my description , a mess ?... nope , what im doing is really simple ,
as i stated in the very first mail , im doing something similar to
RAID 1 !! , what s so hard to understand in that ?
I also said , why im continuing with the IDE modifications inspite of
the RAID 1 drivers.


--snipped--

However, in my driver (modified IDE) I have to take care of the writes
and reads individualy.
The advantage here is that, i dont need to make 4 partitions of the
disk, one is good enough, and the remaining can be unallocated. I make
the write at fixed offsets into the unallocated space, and when read
is requested, I read em one by one, and check.

--snipped--

So now ( after im done with the read requests ) i have two options for them...
RAID 1 and the modified the IDE driver.

Ashwin

[linux-lvm] Re: raid 1 on a single disk

[Peter T. Breuer]

ashwin chaugule <ashwin.chaugule@gmail.com> wrote:
> >Registers?  What registers? Do you mean "fields"?
> 
> yes i mean fields, my bad.

Fields of the request struct, and its buffer head structs, in other
words?  Or fields in the struct that provides your device state
description (or real registers in the device!)!

> >This sounds like stuff you do in the driver , on receipt of your special
> >request.  Is that so and how do you recognize it
> 
> by checking the MAJOR and MINOR num of my disk !!!!! ?

But how do you recognise YOUR request, the one you made?  Are you saying
that you invent a special minor number to use in it?

> >Default interrupt handler? 
> 
> remember i said , i set a different intr. handler if its my disk !? 

I think that what you are saying is that you have a standard 
device driver that handles a whole class of devices, over several
majors, and that you have subverted it to use your driver instead as
a special "personality" if requests arrive for a particular major and minor.

Well, the normal thing to do would be to simply register your driver
for the major and minor. But I guess  you could also do the
"extra personality of existing driver" trick. 


> well, after its handled there, i dont call end_request , simple.
> eg.
> mult_write is the default intr. handler for multiple writes ?
> i set mult_write_withoutend as the handler, then after the handling is
> done , i again set
> mult_write as the handler.... this will call the end_request.

But how do you know you have handled your request? As opposed to a
request somebody else has sent?

> >or whether you only have one request hit the
> >driver and when it hits you simply treat it twice
> 
> bingo !

OK - that is different. It means you never have to worry about
recognizing YOUR request, becuae YOUR request never hits the driver. It
is simply a copy you maintain for reference purposes.

> >Probably because some stuff is returned to kernel pools and messes them
> >up completely.
> 
> what stuff ? im not returning anything to any queue whatsoever !

When you run end_io you are!

> 
> >Because your code, like your description, is an uncontrolled mess,
> >probably.
> 
> about the code .. umm , maybe not , coz the write is duplicated alright ..
> my description , a mess ?... nope , what im doing is really simple ,

Then I suggest you attempt to describe what you are doing. The above
fails!

> as i stated in the very first mail , im doing something similar to
> RAID 1 !! , what s so hard to understand in that ?

Because Raid1 does it, and it does not do what you described.

RAID1, as *I* described, when it gets a write request, looks at all the
buffer heads.  For each buffer head it makes a master raid buffer head
of its own design and links a pair of new buffer heads into it.  It gets
the master and the buffer heads from a private pool, as I recall, to
avoid running out of memory.  The new buffer heads point into the same
buffers as the originals, but point them at different devices.  It's
careful to increment reference counts to stop the buffers vanishing.  It
then submits the buffer heads in the normal way with make request,
having first replaced their end_io functions with dummies that only
decrement a count in the raid master buffer head.  The dummy that zeros
te count is the last to run and it then goes and returns the buffer head
structs to the pool, and kills the master buffer head, and runs the
original end_io's for the original request, telling the user that all
is OK.


> I also said , why im continuing with the IDE modifications inspite of
> the RAID 1 drivers.

I must have not noticed.

> However, in my driver (modified IDE) I have to take care of the writes
> and reads individualy.
> The advantage here is that, i dont need to make 4 partitions of the
> disk, one is good enough, and the remaining can be unallocated. I make

That is not an advantage. It is a disadvantage. Now somebody can 
write partitions in your "free space". ANd now you can't check them
individually in case you need to.

> the write at fixed offsets into the unallocated space, and when read
> is requested, I read em one by one, and check.

What on earth!

> So now ( after im done with the read requests ) i have two options for them...
> RAID 1 and the modified the IDE driver.

If you don't know why the drievr cannot work, then you can be sure it
doesn't, because it won't.  Try streaming data to it.  You should get a
lock up.

Peter

Re: [linux-lvm] Re: raid 1 on a single disk

[ashwin chaugule]

>Then I suggest you attempt to describe what you are doing. The above
>fails!

Its really simple .. dont know why you cant comprehend it.

Hope you understand from the code ... 

in __do_rw_disk

if(MINOR(rq->rq_dev)==69 && rq->cmd==WRITE){
                rq1 = duplicate_request(rq);
                drive->rq=rq1;
        }

where duplicate_request , is a simple kmalloc and memcpy of rq.

rq1 is going to be our duplicate request.

then ....

if(MINOR(rq->rq_dev)==69 && rq->cmd==WRITE)
                        {
                                block_copy = block;
                                get_address(drive,rq1,block);
                        }
else {
                        hwif->OUTB(0x00, IDE_FEATURE_REG);
                        hwif->OUTB(nsectors.b.low, IDE_NSECTOR_REG);
                        hwif->OUTB(block, IDE_SECTOR_REG);
                        hwif->OUTB(block>>=8, IDE_LCYL_REG);
                        hwif->OUTB(block>>=8, IDE_HCYL_REG);
                       
hwif->OUTB(((block>>8)&0x0f)|drive->select.all,IDE_SELECT_REG);
      }
where get_address will do a block=block + (drive->capacity / 2);
and refill all the above registers.

then 

when its a (non DMA) WRITE ...

if(MINOR(rq->rq_dev)==69 && rq->cmd==WRITE)
                                hwgroup->wrq = *rq1; /* scratchpad */
                        else
                                hwgroup->wrq = *rq; /* scratchpad */


then ...

if(MINOR(rq->rq_dev)==69 && rq->cmd==WRITE){
                                rq1->q->queuedata=(void *)rq;

//queuedata is an unused ptr. so it stores the original rq.

                        ide_set_handler(drive,
&multwrite_intr_withoutend, WAIT_CMD, NULL);
                        }
                        else
                        ide_set_handler(drive, &multwrite_intr, WAIT_CMD, NULL);

where ... multiwrite_intr_withoutend is my custom handler ...


now in multiwrite_withoutend

if (rq->nr_sectors) {
                     if (ide_multwrite(drive, drive->mult_count))
                                 return ide_stopped;
                        ide_set_handler(drive,
&multwrite_intr_withoutend, WAIT_CMD, NULL);
                               return ide_started;
                      else

                                ndelay(400);
                                HWGROUP(drive)->handler=0;
                                kfree(drive->rq);
                                drive->rq=(struct request
*)(drive->rq->q->queuedata);
                                hwgroup->wrq = *(drive->rq); /* scratchpad */
                                restore_original_condition(drive);
                                command = ((drive->mult_count) ?
                                ((lba48) ? WIN_MULTWRITE_EXT : WIN_MULTWRITE) :
                                ((lba48) ? WIN_WRITE_EXT : WIN_WRITE));
                                hwif->OUTB(command, IDE_COMMAND_REG);
-snip-
                              ide_set_handler(drive, &multwrite_intr,
WAIT_CMD, NULL);

 etc etc
this is where , i reset the original condition , and set the handler back...
so the original request is completed.

... So you see that , when there's a write request coming to my disk , 

1) duplicate the req.
2) set the handler 
3) perform the write
4) DO NOT call end_request ... so no end_io
5) after its done , restore original condition
6) let it do its thing

Why wont it unmount ?

Ashwin