Re: Documentation on device-mapper and friends

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You should take this to the device mapper list, but I'll try here.

For lurkers, this drawing may be helpful:
http://www.thomas-krenn.com/en/oss/linux-io-stack-diagram/linux-io-stack-diagram_v1.0.pdf

On Wed, May 8, 2013 at 11:15 AM, neha naik <nehanaik27@xxxxxxxxx> wrote:
> Hi Greg,
>   Thanks for the information. I have another question :).
>   Is there some less flexibility if we use device mapper target?
>   For example in block device driver you can use the api such that it won't
> use the OS io scheduler, so the io comes directly to the block device driver
> through the   'make_request' call. With the device mapper i don't think that
> happens(looking at the api calls).

I believe that is correct and one of the reasons DRBD is not part of
DM.  DRBD has various modes including those where it guarantees the
I/Os on both the main target and on the replicated target hit in the
exact same order.  I don't believe that DM can be used to totally
control disk I/O.  It is meant to be stackable, so I think you lose
some exact control.

> Does this mean that stuff like io
> scheduling. barrier control etc is done
>  by the device mapper itself and we can focus only on 'mapping' the io.

As shown in the diagram linked above, DM sits above the i/o schedulers
so you should not have to worry about it.  If you want to play with
schedulers, I think that should be done outside of DM.

Thus I believe you can ignore barriers/scheduling UNLESS you create a
target that needs special barrier/scheduling control.  The obvious
example of something needing that is raid5.  If you get a barrier that
forces data out to a single disk in a raid, you MUST ensure that the
raid checksum is calculated and written out prior to calling the
barrier complete.  That is going to take special handling no matter
what you do.

It's been a couple years since I dug into raid 5/6 as relates to
barriers, but it used to be that code simply didn't do the right thing
in mdraid and DM did not support raid 5/6, so yes the coders could
ignore it, but they created broken logic when they did.

Greg

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux