Wait for an IO to complete

Wait for an IO to complete

[Rishi Agrawal]

Hi All,

I want to wait in my code till the IO actually goes to the disk.

For example

struct buffer_head *bh=sb_bread(sb, 20)

strcpy(bh->b_data, "Some Data");

/* mark and sync */
mark_buffer_dirty(bh);
sync_dirty_buffer(bh);

The above code only adds the bh to the request queue and returns.

I need something

write_buffer_to_disk(bh)

Which will return only if the data has been written on disk.

Please help
-- 

Regards,
Rishi Agrawal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140328/086f3109/attachment.html 

Wait for an IO to complete

[Greg KH]

On Fri, Mar 28, 2014 at 11:16:30PM +0530, Rishi Agrawal wrote:
> Hi All,
> 
> I want to wait in my code till the IO actually goes to the disk.

That's an issue, as you really don't know what a "disk" is from within
the kernel :)

Back up, what exactly are you trying to do?

> For example
> 
> struct buffer_head *bh=sb_bread(sb, 20)
> 
> strcpy(bh->b_data, "Some Data");
> 
> /* mark and sync */
> mark_buffer_dirty(bh);
> sync_dirty_buffer(bh);
> 
> The above code only adds the bh to the request queue and returns.

And that's all you should need.  Why do you feel you need more?

thanks,

greg k-h

Wait for an IO to complete

[Rishi Agrawal]

Hi Greg,

On Fri, Mar 28, 2014 at 11:31 PM, Greg KH <greg@kroah.com> wrote:

> On Fri, Mar 28, 2014 at 11:16:30PM +0530, Rishi Agrawal wrote:
> > Hi All,
> >
> > I want to wait in my code till the IO actually goes to the disk.
>
> That's an issue, as you really don't know what a "disk" is from within
> the kernel :)
>
> Back up, what exactly are you trying to do?
>
> Its a virtual machine, so no worries here, more over I am using a loop
device.


>  > For example
> >
> > struct buffer_head *bh=sb_bread(sb, 20)
> >
> > strcpy(bh->b_data, "Some Data");
> >
> > /* mark and sync */
> > mark_buffer_dirty(bh);
> > sync_dirty_buffer(bh);
> >
> > The above code only adds the bh to the request queue and returns.
>
> And that's all you should need.  Why do you feel you need more?
>
> Actually I am developing a kernel module through which I am writing to the
device. I am not able to the written data in some cases, the code path is
same everywhere. So I thought maybe its not getting flushed on the disk and
I am expecting the write on the disk too early.

I want to wait till the write completes as performance is not I am worried
about right now.


> thanks,
>
> greg k-h
>



-- 
Regards,
Rishi Agrawal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140329/f5c46c08/attachment.html 

Wait for an IO to complete

[Sankar P]

2014-03-28 23:16 GMT+05:30 Rishi Agrawal <rishi.b.agrawal@gmail.com>:
> Hi All,
>
> I want to wait in my code till the IO actually goes to the disk.
>
> For example
>
> struct buffer_head *bh=sb_bread(sb, 20)
>
> strcpy(bh->b_data, "Some Data");
>
> /* mark and sync */
> mark_buffer_dirty(bh);
> sync_dirty_buffer(bh);
>
> The above code only adds the bh to the request queue and returns.
>

My memory is very rusty. So I may be wrong.

Look for what sync_filesystem does.

However, there is no guarantee that the data will be actually written
to disk. I have heard instances where a caching layer in the disk
tells the filesystem that the data is written but the data was not
written and there was a power failure and an ensuing loss of data.

So from the filesystem side, you can only provide a somewhat
unreliable confirmation only most of the times.

> I need something
>
> write_buffer_to_disk(bh)
>
> Which will return only if the data has been written on disk.
>
> Please help
> --
>
> Regards,
> Rishi Agrawal
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Sankar P
http://psankar.blogspot.com

Wait for an IO to complete

[Valdis.Kletnieks at vt.edu]

On Sat, 29 Mar 2014 18:17:52 +0530, Sankar P said:

> However, there is no guarantee that the data will be actually written
> to disk. I have heard instances where a caching layer in the disk
> tells the filesystem that the data is written but the data was not
> written and there was a power failure and an ensuing loss of data.

Actually, let me go a step further - I know of no current disks which
support write caching that *don't* lie to the OS and say "I/O complete,
data is on the disk" when it lands in the cache (leaving you vulnerable
if there's a power hit before it flushes the cashe).

Even more evil - although you'd *think* that the solution is to just disable
the write cache so the disk can't lie and has to wait for the data to hit
the platters, that's not quite true.  There's been disks (especially on the
very low end where they Just Don't Care, and on the high end were numbers
are everything) that will *say* they disabled the write cache, but it's still
doing it inside....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140330/87b176dc/attachment.bin 

Wait for an IO to complete

[Rishi Agrawal]

Thanks all,


On Sun, Mar 30, 2014 at 9:59 PM, <Valdis.Kletnieks@vt.edu> wrote:

> On Sat, 29 Mar 2014 18:17:52 +0530, Sankar P said:
>
> > However, there is no guarantee that the data will be actually written
> > to disk. I have heard instances where a caching layer in the disk
> > tells the filesystem that the data is written but the data was not
> > written and there was a power failure and an ensuing loss of data.
>
> Actually, let me go a step further - I know of no current disks which
> support write caching that *don't* lie to the OS and say "I/O complete,
> data is on the disk" when it lands in the cache (leaving you vulnerable
> if there's a power hit before it flushes the cashe).
>
> Even more evil - although you'd *think* that the solution is to just
> disable
> the write cache so the disk can't lie and has to wait for the data to hit
> the platters, that's not quite true.  There's been disks (especially on the
> very low end where they Just Don't Care, and on the high end were numbers
> are everything) that will *say* they disabled the write cache, but it's
> still
> doing it inside....
>


Though I can't be still sure of that the data has been flushed to disk

something like wait_on_buffer() will help me a bit

I am still curious to know what happens in journalling, as the journal
NEEDS to be committed to the disk, before data writes/modifcation proceed.

Same for Direct IO as Vineet Suggested

I could not look at the code, will look the code.

-- 
Regards,
Rishi Agrawal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140401/79513446/attachment.html