From: Aboo Valappil <aboo@aboo.org>
To: linux-scsi@vger.kernel.org
Subject: Re: About SG Elements of request_buffer
Date: Wed, 25 Oct 2006 19:05:09 +1000 [thread overview]
Message-ID: <453F28C5.5000104@aboo.org> (raw)
In-Reply-To: <453223AA.50409@aboo.org>
[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]
Hi All,
I have posted this a while ago on strange behavior I see when "dd" opens
and reads the disk presented by my virtual HBA. I am attaching the code
in this email.
Basically, I have this virtual HBA which is being served by a user space
SCSI engine. It basically transports SCSI commands out side kernel and
get serviced by a user space scsi engine.
I have successfully implemented this using read and write system call to
a character device. So the SCSI request buffer is copied back and forth
user and kernel space for every request. It works alright.
Now i wanted a method of sharing SCSI request_buffer between user space
and kernel without doing copy_to_user and copy_from_user of the
request_buffer. I have implemented memmap and facing some challenges. I
am memory mapping the scsi request_buffer to the user space. But i am
facing a problem with page cache.
The SCSI device presented by my HBA is /dev/sdb (for eg:). If I open
this device and read a block ( 512 bytes). I can see a SCSI read coming
down my HBA. But I also a see a SCSI write later on when I close
/dev/sdb. Up on investigation I found that it is the effect of page
cache. When /dev/sdb opened and initiated a read, a page cache is
already allocated. When I do memmap, I am actually mem mapping that page
buffer to my user space SCSI engine. When the SCSI engine service the
SCSI read, it writes the SCSI READ output to the buffer making it dirty.
When the application closed /dev/sdb, the kernel causes all the dirty
pages to be written and causing the SCSI write which is what I am
seeing. This means that for every SCSI read, i will see a SCSI write.It
is a very strange implementation from my side. Even Xen source is doing
the same memory mapping technique and I do not know how it avoid this
page cache interference.
Can some one throw some lights on this for me to prevent this page cache
interference? I have done bit of research on marking the pages/buffer
clean after writing to the memory mapped area. But I could not find
anything conclusive.
Thanks in advance,
Aboo
Aboo Valappil wrote:
> Hi All,
>
> Thanks for all your support for my previous posts.
>
> I have two questions.
>
> 1. Is it safe to assume that all the SG elements of request_buffer are
> page aligned? (Except the first one and last one), I mean, it is
> always multiple of pages?
>
> 2. What are situations reading a scsi disk (using dd ) cause a write
> to the disk? When I read my virtual scsi disk using dd command, block
> layer is generating lot of SCSI write, as well as reads. Any thoughts?
> Besides this observation, everything is working fine.
>
> Thanks in advance.
>
> Aboo
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: scsitap.tgz --]
[-- Type: application/octet-stream, Size: 4755 bytes --]
prev parent reply other threads:[~2006-10-25 9:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-15 12:03 About SG Elements of request_buffer Aboo Valappil
2006-10-15 15:40 ` Douglas Gilbert
2006-10-15 15:53 ` James Bottomley
2006-10-25 9:05 ` Aboo Valappil [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=453F28C5.5000104@aboo.org \
--to=aboo@aboo.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox