linux-kernel - Re: [PATCH] ext4: Fix up range_end offset in range cyclic writeback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1326126051.97658.YahooMailNeo@web38008.mail.mud.yahoo.com>
Date:	Mon, 9 Jan 2012 08:20:51 -0800 (PST)
From:	Shantanu Goel <sgoel01@...oo.com>
To:	Ted Ts'o <tytso@....edu>
Cc:	Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ext4: Fix up range_end offset in range cyclic writeback

> So this was a performance issue that led you to this investigation?
> How much of a performance issue are we talking about?

It's a performance issue in the sense that background flush of the file can take much longer (we observed > 5 mins in some instances) than the 30 second kupdate interval.

> If it's a correctness issue that might lead to data loss because
> fsync() wasn't doing its jobs, that's obviously higher priority than a
> performance issue.

fsync() is not affected and works correctly with or without the patch since it does not use the range_cyclic writeback mode, AFAICT.  The only "correctness" issue would be if an application relies on kupdate which uses range_cyclic writeback to periodically flush the file as governed by the /proc/sys/vm/dirty_writeback_centisecs tunable.  We have some applications which lost more data than they expected due to the writeback not happening at expected intervals.  One could argue the bug is in the application since it could have guaranteed the file was flushed by using fsync hence my quotes around correctness.  Unfortunately, modifying the application is not an easy option for us to pursue at this time.  We just wish to have the patch merged upstream and the exact timing is not that critical.

> Again, I just wanted to characterize this correctly in the commit ---
> BTW, this is good stuff to include in the commit description so in the
> future, developers trying to go through the history can understand why
> a particular patch is important (perhaps to backport into an
> enterprise distro release, etc.)

Sure, will do in future.

Thanks,
Shantanu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/