On 10/09/2015 03:50 PM, Ivan Shapovalov wrote:
On 2015-10-09 at 15:27 +0200, Edward Shishkin wrote:
Hi Ivan,
On 10/09/2015 01:16 PM, Ivan Shapovalov wrote:
Ref.: https://www.mail-archive.com/linux-f2fs-devel%40lists.sourcef
orge.net/msg02745.html
Do you have a stack trace for reiser4?
How to reproduce it?
I'll rebuild the kernel without the fix and provide you with the oops'
stacktrace asap.
I guess that it's tied to the config. In my case, it is reproducible on
each boot, just as the DE starts up and something issues the first
fsync().
Yes, let's try to find the culprit who doesn't set i_wb...
Signed-off-by: Ivan Shapovalov <intelfx100@xxxxxxxxx>
---
Lustre seemed to encounter the same oops and fixed it in a
different way, removing
set_page_writeback() altogether:
https://lkml.org/lkml/2015/7/30/806
We cannot just remove the call to set_page_writeback() at least
because later
we wait on PG_Writeback flag of that page (in jwait_io())... What
is meant by
"synchronous write" in that Lustre patch? Is our write
"synchronous" in the
same sense?
Nop.
This is a generic function, it doesn't differentiate the writes.
Well, that lustre vvp_page_prep_write() is generic as well, and that
patch adds a conditional to differentiate sync/async writes. What is
meant by "sync" in that context? sync == page is locked until I/O ends?
Or something else?
Why do you need this?
Reiser4 doesn't lock pages for IO ;)
At least, for formatted nodes..
Edward.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
