On Fri, Mar 14, 2014 at 10:54:30AM -0400, Tejun Heo wrote:
> This is a bit surprising tho. Were we always like this? We never had
> even stupid "flush down everything and sync"? Or is this something we
> broke while morphing flush implementation several times in the past
> years?
It's something
On Fri, Mar 14, 2014 at 11:11 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Mar 14, 2014 at 11:07:04PM +0900, Roman Peniaev wrote:
>> Seems the following message should be better:
>> When data inegrity operation (sync, fsync, fdatasync calls) happens
>> writeback control is set to WB_SYNC_ALL.
>> In t
On Fri 14-03-14 10:54:30, Tejun Heo wrote:
> On Fri, Mar 14, 2014 at 03:52:15PM +0100, Jan Kara wrote:
> > Well, for ext2, you can use ext4 kernel driver which takes care of
> > REQ_FLUSH properly. For fat, you'll need to fix the fs...
>
> This is a bit surprising tho. Were we always like this?
On Fri, Mar 14, 2014 at 03:52:15PM +0100, Jan Kara wrote:
> Well, for ext2, you can use ext4 kernel driver which takes care of
> REQ_FLUSH properly. For fat, you'll need to fix the fs...
This is a bit surprising tho. Were we always like this? We never had
even stupid "flush down everything and
On Fri 14-03-14 23:23:45, Roman Peniaev wrote:
> On Fri, Mar 14, 2014 at 11:15 PM, Jan Kara wrote:
> > On Fri 14-03-14 10:11:43, Tejun Heo wrote:
> >> > Also, could you please help me do understand how can I guarantee
> >> > integrity in case of block device with big volatile
> >> > cache and file
On Fri, Mar 14, 2014 at 11:20 PM, Tejun Heo wrote:
> On Fri, Mar 14, 2014 at 11:17:56PM +0900, Roman Peniaev wrote:
>> No, no. Not device does not support flush, filesystem does not care about
>> flush.
>> (take any old school, e.g. ext2)
>>
>> We did some write, and then we did fsync.
>> But fil
On Fri, Mar 14, 2014 at 11:15 PM, Jan Kara wrote:
> On Fri 14-03-14 10:11:43, Tejun Heo wrote:
>> > Also, could you please help me do understand how can I guarantee
>> > integrity in case of block device with big volatile
>> > cache and filesystem, which does not support REQ_FLUSH/FUA?
>>
>> If a
On Fri, Mar 14, 2014 at 11:17:56PM +0900, Roman Peniaev wrote:
> No, no. Not device does not support flush, filesystem does not care about
> flush.
> (take any old school, e.g. ext2)
>
> We did some write, and then we did fsync.
> But filesystem does not support REQ_FLUSH/FUA so block device will
On Fri, Mar 14, 2014 at 11:11 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Mar 14, 2014 at 11:07:04PM +0900, Roman Peniaev wrote:
>> Seems the following message should be better:
>> When data inegrity operation (sync, fsync, fdatasync calls) happens
>> writeback control is set to WB_SYNC_ALL.
>> In t
On Fri 14-03-14 10:11:43, Tejun Heo wrote:
> > Also, could you please help me do understand how can I guarantee
> > integrity in case of block device with big volatile
> > cache and filesystem, which does not support REQ_FLUSH/FUA?
>
> If a device has a volatile cache but doesn't support flush, it
Hello,
On Fri, Mar 14, 2014 at 11:07:04PM +0900, Roman Peniaev wrote:
> Seems the following message should be better:
> When data inegrity operation (sync, fsync, fdatasync calls) happens
> writeback control is set to WB_SYNC_ALL.
> In that case all write requests are marked with WRITE_SYNC, but o
Hello, Tejun.
On Fri, Mar 14, 2014 at 10:07 PM, Tejun Heo wrote:
> Hello, Andrew.
>
> On Thu, Mar 13, 2014 at 02:34:56PM -0700, Andrew Morton wrote:
>> Jens isn't talking to us. Tejun, are you able explain REQ_SYNC?
>
> It has nothing to do with data integrity. It's just a hint telling
> the bl
Hello, Andrew.
On Thu, Mar 13, 2014 at 02:34:56PM -0700, Andrew Morton wrote:
> Jens isn't talking to us. Tejun, are you able explain REQ_SYNC?
It has nothing to do with data integrity. It's just a hint telling
the block layer that someone is waiting for the IO so it'd be a good
idea to priorit
On Thu, 13 Mar 2014 21:01:19 +0100 Jan Kara wrote:
> Hello,
>
> On Wed 12-03-14 23:29:04, Roman Peniaev wrote:
> > could you please explain the real purpose of WAIT_SYNC?
> > In case of wbc->sync_mode == WB_SYNC_ALL.
> > Because my current understanding is if writeback control has
> > WB_SYNC_
On Sun 16-02-14 11:54:28, Roman Pen wrote:
> In case of wbc->sync_mode == WB_SYNC_ALL we need to do data integrity write,
> thus mark request as WRITE_SYNC.
The patch looks good to me and also makes generic mpage code more in sync
with what e.g. XFS or ext4 do in their writepage functions. You ca
Hello,
On Wed 12-03-14 23:29:04, Roman Peniaev wrote:
> could you please explain the real purpose of WAIT_SYNC?
> In case of wbc->sync_mode == WB_SYNC_ALL.
> Because my current understanding is if writeback control has
> WB_SYNC_ALL everything
> should be submitted with WAIT_SYNC.
So AFAIK the
Jens,
could you please explain the real purpose of WAIT_SYNC?
In case of wbc->sync_mode == WB_SYNC_ALL.
Because my current understanding is if writeback control has
WB_SYNC_ALL everything
should be submitted with WAIT_SYNC.
--
Roman
On Wed, Feb 19, 2014 at 10:38 AM, Roman Peniaev wrote:
> (my
(my previous email was rejected by vger.kernel.org because google web
sent it as html.
will resend the same one in plain text mode)
> What do REQ_SYNC and REQ_NOIDLE actually *do*?
Yep, this REQ_SYNC is very confusing to me.
First of all according to the sources of old school block buffer filesy
On Sun, 16 Feb 2014 11:54:28 +0900 Roman Pen wrote:
> In case of wbc->sync_mode == WB_SYNC_ALL we need to do data integrity write,
> thus mark request as WRITE_SYNC.
gargh, the documentation for this stuff is useless.
What do REQ_SYNC and REQ_NOIDLE actually *do*?
For mpage writes, REQ_NOIDLE
In case of wbc->sync_mode == WB_SYNC_ALL we need to do data integrity write,
thus mark request as WRITE_SYNC.
Signed-off-by: Roman Pen
CC: Alexander Viro
CC: linux-fsde...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
fs/mpage.c | 23 +++
1 file changed, 15 insertions
20 matches
Mail list logo
