linux-kernel - Re: [PATCH 2/3] fscache/cachefiles: optionally use SEEK

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

Message-ID: <20150422090653.35ad074c@notabene.brown>
Date:	Wed, 22 Apr 2015 09:06:53 +1000
From:	NeilBrown <neilb@...e.de>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	David Howells <dhowells@...hat.com>, Chris Mason <clm@...com>,
	Al Viro <viro@...IV.linux.org.uk>, Josef Bacik <jbacik@...com>,
	David Sterba <dsterba@...e.cz>, linux-cachefs@...r.kernel.org,
	Dave Chinner <david@...morbit.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-btrfs@...r.kernel.org
Subject: Re: [PATCH 2/3] fscache/cachefiles: optionally use SEEK_DATA
 instead of ->bmap.

On Mon, 20 Apr 2015 02:45:39 -0700 Christoph Hellwig <hch@...radead.org>
wrote:

> On Mon, Apr 20, 2015 at 04:27:00PM +1000, NeilBrown wrote:
> > A worthwhile goal, but I certainly wouldn't consider pursuing it until what I
> > have submitted so far as been accepted - let's not reject "good" while
> > waiting for "perfect".
> 
> It's still broken.  You add conditional flag for the almost right
> (almost because the flag in the filesystem type needs to go)

Why does it have to go?  I suspect you have a reason, but I can't read your
mind.

>  while
> leaving the broken option th default. 

You say it is broken, and yet people are using it and are having a degree of
success.

Surely the appropriate process is:
 - introduce a "better" option
 - examine each relevant filesystem and transition over to use the new option.
 - remove the "not so good" option.

I'm still at step 1.

>   So what you propose here is not
> good, it's at best just as bad as the old version because you don't
> remove broken code but add a lot more clutter at the same time.

What I propose is measurably better because it works with BTRFS now, and
there seems to be a reasonable path towards making to generally better if
someone cares enough to examine each filesystem.

So I still claim you are pushing back against "good" because you want
"perfect".

NeilBrown

Content of type "application/pgp-signature" skipped