On Fri, Mar 14, 2014 at 11:11 PM, Tejun Heo <tj@xxxxxxxxxx> 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 that case all write requests are marked with WRITE_SYNC, but on >> mpage writeback path >> WRITE_SYNC is missed. This patch fixes this. >> >> Is it ok, what do you think? > > I think the description should make it clear that WRITE_SYNC is about > latency, not about integrity and we probably should add comments > explaining why we're using WRITE_SYNC for WB_SYNC_ALL (because there > probably is someone waiting). > >> 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 can't > guarantee integrity. There's no way for its user to determine or > force whether certain data is on non-volatile media. It's an > inherently broken device. 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 never get the checkpoint where it should really flush everything. So, fsync will not guarantee any integrity in that case. > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
