linux-ext4 - jbd2 batch time tuning behavior question

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-next>] [day] [month] [year] [list]

Message-ID: <5384C18A.7040501@redhat.com>
Date:	Tue, 27 May 2014 11:47:06 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	ext4 development <linux-ext4@...r.kernel.org>
Subject: jbd2 batch time tuning behavior question

Question for Ted:  With this commit, you introduced some documentation and some code which are not consistent AFAICT:


commit 30773840c19cea60dcef39545960d541b1ac1cf8
Author: Theodore Ts'o <tytso@....edu>
Date:   Sat Jan 3 20:27:38 2009 -0500

    ext4: add fsync batch tuning knobs

<snip>

+                       the transaction.   The commit time is capped by
+                       the max_batch_time, which defaults to 15000us
+                       (15ms).   This optimization can be turned off
+                       entirely by setting max_batch_time to 0.

<snip>

+               case Opt_max_batch_time:
+                       if (match_int(&args[0], &option))
+                               return 0;
+                       if (option < 0)
+                               return 0;
+                       if (option == 0)
+                               option = EXT4_DEF_MAX_BATCH_TIME;
+                       sbi->s_max_batch_time = option;
+                       break;

Docs say "0" turns it off, but option handling turns "0" into 
EXT4_DEF_MAX_BATCH_TIME.  What was the real intent here; should the
docs or the behavior be changed?

Thanks,
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html