You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First I want to tell that I thank you for the great document very very much.
I have a question about the ram-disk example.
When the user application opens a block file, I think the buffer-cache works between the driver and filesystem.
So I ran the ram-disk-test program without solving TODO 3.
Below is what I got when running ram-disk-test program without solving TODO 3.
What I guess:
READ happened when accessing sector 0, 8, 16 ...
So I guess the unit size of buffer-cache layer is 8*512 = 4096 bytes.
Application reads each sector and write each sector.
But driver only does write. So I guess the application reads only the cached data.
Only when application writes data, the buffer-cache layer writes data.
Therefore I guess the ram-disk-test program needs to use O_DIRECT flag.
So I re-build it with O_DIRECT flag.
Below is what I got.
All accessing failed.
Device driver did nothing.
/ # ./ramdisktest d
insmod ./ram-disk.ko
[ 4.929450] ram_disk: loading out-of-tree module taints kernel.
mknod /dev/myblock b 240 0
[ 6.985266] my_block_open
use direct io
test sector 0 ... failed
test sector 1 ... failed
test sector 2 ... failed
test sector 3 ... failed
test sector 4 ... failed
test sector 5 ... failed
test sector 6 ... failed
test sector 7 ... failed
test sector 8 ... failed
..........................................skip.......................
I don't understand why the driver did nothing when using O_DIRECT flag.
Here I attached ram-disk-test program code and ram-disk driver code.
Could you please inform me what I did wrong?
And please inform me whether the user application needs O_DIRECT flag or not.
Are you still seeing this (realize it's nearly a year later)? I was trying today and having the exact same problem. I came to the same conclusion you did- maybe a buffer layer exists which caches the data so the read() doesn't actually do the block request? Also saw the 4096 byte requests.
Why does it generate only read request?
When a new device /dev/myblock, udevadm generates an event and systemd(or something else) reads some kilobytes of the block device. There is a readahead file in /sys/block/myblock/queues. I guess that's why. If you generate bigger block device and try to read the last sector, you could be able to see read-request.
Why does the driver fail with direct IO?
I didn't get it yet. I guess the driver should do something else with direct IO. I thought there should be some code in the brd driver in kernel but I didn't try it because I stopped reading the document.
Please inform me you find something.
Hi,
First I want to tell that I thank you for the great document very very much.
I have a question about the ram-disk example.
When the user application opens a block file, I think the buffer-cache works between the driver and filesystem.
So I ran the ram-disk-test program without solving TODO 3.
Below is what I got when running ram-disk-test program without solving TODO 3.
What I guess:
So I guess the unit size of buffer-cache layer is 8*512 = 4096 bytes.
But driver only does write. So I guess the application reads only the cached data.
Only when application writes data, the buffer-cache layer writes data.
Therefore I guess the ram-disk-test program needs to use O_DIRECT flag.
So I re-build it with O_DIRECT flag.
Below is what I got.
I don't understand why the driver did nothing when using O_DIRECT flag.
Here I attached ram-disk-test program code and ram-disk driver code.
Could you please inform me what I did wrong?
And please inform me whether the user application needs O_DIRECT flag or not.
The text was updated successfully, but these errors were encountered: