> 在 2017年12月11日，下午9:20，Chengguang Xu <cgxu519@xxxxxxxxxx> 写道： > >> >> 在 2017年12月11日，下午8:44，Amir Goldstein <amir73il@xxxxxxxxx> 写道： >> >> On Mon, Dec 11, 2017 at 2:33 PM, Chengguang Xu <cgxu519@xxxxxxxxxx> wrote: >>>> >>>> 在 2017年12月11日，下午6:46，Amir Goldstein <amir73il@xxxxxxxxx> 写道： >>>> >>>> On Mon, Dec 11, 2017 at 12:03 PM, Chengguang Xu <cgxu519@xxxxxxxxxx> wrote: >>>>>> >>>>>> 在 2017年12月7日，下午4:17，Amir Goldstein <amir73il@xxxxxxxxx> 写道： >>>> [...] >>>>> >>>>> I did more detail tests for three different data modes of ext4 and found >>>>> the overlayfs syncfs bug is reproducible on data=ordered and data=writeback, >>>>> but on data=journal mode, data is flushed and correct. >>>> >>>> That is expected, because overlayfs does call upper's sync_fs() method and >>>> for journal=data that will flush all dirty pages as well. >>>> >>>>> I only wrote only a few words >>>>> to a single file and the bug is always reproducible on my test environment. >>>>> >>>>> For writeback interferences, AFAIK, from dirty ratio and period. >>>>> If we drop all dirty caches & sync before the test, I think we can >>>>> avoid interference from it. >>>>> >>>> >>>> Why? does either drop_caches or sync() reset the flusher thread >>>> periodic flush dirty pages? >>> >>> Sorry，We have to finish test in 30 seconds after we write test file, >>> otherwise may be affected by background flusher. >>> >>> >>>> >>>>> So if we don’t have anything else to interference test result, >>>>> I just want to modify to write a small single file as test target. >>>>> >>>>> Am I missing anything? >>>> >>>> I think the chance of flusher thread interfering the test and >>>> flushing the dirty page you wrote before _scratch_shutdown exists, >>>> but is small enough so we can neglect it and keep the test as simple >>>> as possible. >>> >>> As I know, in normal case flusher thread check dirty inode expiring every 5 seconds(default) and flush dirty >>> inode when expires 30 seconds(default). If we can finish test in 30s after running test, it would be OK. >>> What do you think? >>> >> >> 5 seconds is ext4 default journal commit interval. this is when dirty >> metadata will be flushed. >> 30 is generic flusher thread interval. >> What if test started 29 seconds after last flush? > > Maybe we have misunderstanding about the flushing intervals. > I’m saying the intervals which are under /proc/sys/vm to control > writeback behaviors, it seems not related to any specific filesystem > like ext4 or others. > > dirty_expire_interval > default:3000(millisecond) > > dirty_writeback_interval > default:500(millisecond) Correction: dirty_expire_interval default:3000(centiseconds) dirty_writeback_interval default:500(centiseconds) > > Anyway, let me modify test case base on our discussion. > > >> >> I am saying that the chances of interference from flusher thread are quite >> if the test is very quick. >> >> If you create files and sync at the start of the test, overlayfs >> syncfs will call >> ext4 sync_fs and that will have nothing to do, because no metadata is dirty, >> so test will be quick and we can neglect that change of interference. >> >> *If* you wish to reduce that chance for interference loop the test twice, but >> I don't think that's a must. >> >> Amir. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
