linux-ext4 - Re: [PATCH] ext4: add an interface to load block bitmaps

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: <20180524170014.GA7712@thunk.org>
Date:   Thu, 24 May 2018 13:00:14 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Jan Kara <jack@...e.cz>
Cc:     Andreas Dilger <adilger@...ger.ca>,
        Wang Shilong <wangshilong1991@...il.com>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Wang Shilong <wshilong@....com>
Subject: Re: [PATCH] ext4: add an interface to load block bitmaps

On Thu, May 24, 2018 at 10:42:43AM +0200, Jan Kara wrote:
> 
> Yes, it's more complexity but pinning is OTOH user visible API so that has
> some maintenance overhead as well as we have to maintain it indefinitely.
> And your hack with dumpe2fs works good enough (as much as hit's ugly) that I
> don't think we need to hurry some half baked solutions...

If the user-visible API is a mount option, it's really not that hard
deprecate it later in favor of something which is done automatically
via some kind of compressed in-memory pinning mechanism --- we would
just turn the mount option into a no-op plus a print-once warning
message saying it's no longer needed.

Jan's design makes much more sense as the long-term direction --- and
if the good folks at DDN are willing to code it, I would be greatly
pleased.  That being said, if they only want the short-term hack, my
primary concern is code maintenance and complexity issue.  If there is
a simple for loop that calls the existing functions to load the block
bitmap, and then pin them by bumping the ref count, I'm not going to
object that much.  What I didn't like about the inital patch was the
large number of new code that duplicates existing functionality, since
that's a code maintenance burden.

I will say that if we use an rbtree of free block extents, we could
probably use this instead of the buddy bitmaps, and the resulting code
could probably do a better job finding free blocks and reducing
fragmentation.  So that's another reason to go down the patch
suggested by Jan.

Regards,

					- Ted