On Tue, Aug 11, 2009 at 03:35:36PM +0200, Frans Pop wrote:
quoted
Somewhat unrelated, but what happened to the data=guarded patches
Chris Mason proposed back in April?
I missed 2.6.31 but plan on sending for 2.6.32. I promised to send
along a forward port of the patches a while back, but I finally have
one in testing here. It should go out shortly.
Good to hear. I've so far stayed with data=ordered as I think I'd prefer
data=guarded over data=writeback. I'll certainly give it a try when it's
available.
Same here. data=writeback already cost me a few files after crashes here :/
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
From: Jan Kara <jack@suse.cz> Date: 2009-08-11 15:34:27
Frans Pop [off-list ref] writes:
quoted
On Tuesday 11 August 2009, Chris Mason wrote:
quoted
On Tue, Aug 11, 2009 at 03:35:36PM +0200, Frans Pop wrote:
quoted
Somewhat unrelated, but what happened to the data=guarded patches
Chris Mason proposed back in April?
I missed 2.6.31 but plan on sending for 2.6.32. I promised to send
along a forward port of the patches a while back, but I finally have
one in testing here. It should go out shortly.
Good to hear. I've so far stayed with data=ordered as I think I'd prefer
data=guarded over data=writeback. I'll certainly give it a try when it's
available.
Same here. data=writeback already cost me a few files after crashes here :/
In this regard, data=guarded need not be better than data=writeback.
We push out the data in guarded mode as late as in writeback mode
(that's where the performance benefit comes from ;). The difference is
that we increase i_size only after data are safely on disk so we cannot
expose old data.
So security-wise, guarded mode is as safe as ordered mode but in other
aspects its more like data=writeback.
Honza
--
Jan Kara [off-list ref]
SuSE CR Labs
From: Eric Sandeen <hidden> Date: 2009-08-11 18:05:11
Jan Kara wrote:
quoted
Frans Pop [off-list ref] writes:
quoted
On Tuesday 11 August 2009, Chris Mason wrote:
quoted
On Tue, Aug 11, 2009 at 03:35:36PM +0200, Frans Pop wrote:
quoted
Somewhat unrelated, but what happened to the data=guarded patches
Chris Mason proposed back in April?
I missed 2.6.31 but plan on sending for 2.6.32. I promised to send
along a forward port of the patches a while back, but I finally have
one in testing here. It should go out shortly.
Good to hear. I've so far stayed with data=ordered as I think I'd prefer
data=guarded over data=writeback. I'll certainly give it a try when it's
available.
Same here. data=writeback already cost me a few files after crashes here :/
In this regard, data=guarded need not be better than data=writeback.
We push out the data in guarded mode as late as in writeback mode
(that's where the performance benefit comes from ;). The difference is
that we increase i_size only after data are safely on disk so we cannot
expose old data.
So security-wise, guarded mode is as safe as ordered mode but in other
aspects its more like data=writeback.
Yes, I think the people anxiously waiting for data=guarded may be sadly
surprised at their 0-length files.
For those who understand the data=writeback tradeoffs it'll be very
useful in terms of more consistent results (easily-detectable 0-size or
short files, vs. randomly corrupted data sprinkled around) but it's not
going to be "data=ordered, but faster!"
-Eric
On Tue, Aug 11, 2009 at 05:29:14PM +0200, Andi Kleen wrote:
quoted
Good to hear. I've so far stayed with data=ordered as I think I'd prefer
data=guarded over data=writeback. I'll certainly give it a try when it's
available.
Same here. data=writeback already cost me a few files after crashes here :/
What sort of files were you losing? I don't know if we can improve
the implied flush hueristics, but we should at least try to see if we
do something about it.
- Ted
On Tue, Aug 11, 2009 at 02:57:03PM -0400, Theodore Tso wrote:
On Tue, Aug 11, 2009 at 05:29:14PM +0200, Andi Kleen wrote:
quoted
quoted
Good to hear. I've so far stayed with data=ordered as I think I'd prefer
data=guarded over data=writeback. I'll certainly give it a try when it's
available.
Same here. data=writeback already cost me a few files after crashes here :/
What sort of files were you losing? I don't know if we can improve
the implied flush hueristics, but we should at least try to see if we
do something about it.
Common case is something patched or git checkout shortly (but not
as short as in seconds) before the crash.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
From: Pavel Machek <hidden> Date: 2009-08-11 21:02:18
On Tue 2009-08-11 14:57:03, Theodore Tso wrote:
On Tue, Aug 11, 2009 at 05:29:14PM +0200, Andi Kleen wrote:
quoted
quoted
Good to hear. I've so far stayed with data=ordered as I think I'd prefer
data=guarded over data=writeback. I'll certainly give it a try when it's
available.
Same here. data=writeback already cost me a few files after crashes here :/
What sort of files were you losing? I don't know if we can improve
the implied flush hueristics, but we should at least try to see if we
do something about it.
From: Jan Kara <jack@suse.cz> Date: 2009-08-12 20:37:58
On Mon 10-08-09 18:42:05, Pavel Machek wrote:
On Tue 2009-08-11 14:57:03, Theodore Tso wrote:
quoted
On Tue, Aug 11, 2009 at 05:29:14PM +0200, Andi Kleen wrote:
quoted
quoted
Good to hear. I've so far stayed with data=ordered as I think I'd prefer
data=guarded over data=writeback. I'll certainly give it a try when it's
available.
Same here. data=writeback already cost me a few files after crashes here :/
What sort of files were you losing? I don't know if we can improve
the implied flush hueristics, but we should at least try to see if we
do something about it.
IIRC... the flush heuristics invoke async flush, so you can still lose
data if you are unlucky, no?
Of course you can but it can happen in data=ordered mode as well (if the
machine crashes before the transaction is committed). The percieved
difference is in the fact that kjournald starts its commit every 5 seconds
while pdflush starts writeback every 30-35 seconds. So if you use
data=guarded/writeback mode and set dirty_expire_centisecs to 500, the
experience wrt. data loss is going to be similar to data=ordered mode.
fsync with heavy background writers won't be that painful as in data=ordered
mode but apart from that the performance will be probably comparable.
Honza
--
Jan Kara [off-list ref]
SUSE Labs, CR