3

I am looking for a way to monitor access to disk blocks, and to monitor the access as a bitmap of blocks.

I also need the capability to freeze (and queue) the device block access (and also to unfreeze and write the pending blocks). Seems that this features must be supported at kernel mode (can't be done probably as a user application). In kernel there is blk-core.c which probably is the gate before calling the actual block device. I thought that I can use that for this purpose.

It seems that is already uses some queue mechanism, and that I would need some way to understand when the actual writing to device is done.

void blk_start_queue(struct request_queue *q)
{
    WARN_ON(!irqs_disabled());

        queue_flag_clear(QUEUE_FLAG_STOPPED, q);
           __blk_run_queue(q);
 }
 EXPORT_SYMBOL(blk_start_queue);

I also see that it uses sectors, not blocks (which is what I need to trace).

Is it that the kernel filesystem write request is in sectors, while the below device driver of disk works in blocks ? If yes, than block monitoring must be in the disk driver instead.

I also not sure about the device block itself (for example , hd.c) The request structure contain the exact place where the trasfer should be made:

    struct request
     {
       ....
       sector  // the position in the device at which the transfer should be made
      ....
    }

gives information about the exact sector to read/write, but how does the layer above which send the request can decide about it ? Isn't it the decision of the block driver (hd.c in this case) to take ?

I probably missing something in my understand.

Thank you for any suggestions on the subject.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.