[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191217004419.GA6833@ZenIV.linux.org.uk>
Date: Tue, 17 Dec 2019 00:44:19 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Lukas Czerner <lczerner@...hat.com>
Cc: linux-ext4@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 02/17] ext4: Add fs parameter description
On Wed, Nov 06, 2019 at 11:14:42AM +0100, Lukas Czerner wrote:
> + fsparam_string_empty
> + ("usrjquota", Opt_usrjquota),
> + fsparam_string_empty
> + ("grpjquota", Opt_grpjquota),
Umm... That makes ...,usrjquota,... equivalent to ...,usrjquota=,...
unless I'm misreading the series. Different from mainline, right?
> + fsparam_bool ("barrier", Opt_barrier),
> + fsparam_flag ("nobarrier", Opt_nobarrier),
That's even more interesting. Current mainline:
barrier OK, sets EXT4_MOUNT_BARRIER
barrier=0 OK, sets EXT4_MOUNT_BARRIER
barrier=42 OK, sets EXT4_MOUNT_BARRIER
barrier=yes error
barrier=no error
nobarrier OK, clears EXT4_MOUNT_BARRIER
Unless I'm misreading your series, you get
barrier error
barrier=0 OK, sets EXT4_MOUNT_BARRIER
barrier=42 error
barrier=yes OK, sets EXT4_MOUNT_BARRIER
barrier=no OK, sets EXT4_MOUNT_BARRIER
nobarrier OK, clears EXT4_MOUNT_BARRIER
Granted, mainline behaviour is... unintuitive, to put it mildly,
but the replacement is just as strange _and_ incompatible with the
existing one.
Am I missing something subtle there?
Powered by blists - more mailing lists