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 for Android: free password hash cracker in your pocket

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

Message-ID: <20180516025810.GE17777@thunk.org>
Date:   Tue, 15 May 2018 22:58:10 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Wang Shilong <wangshilong1991@...il.com>
Cc:     linux-ext4@...r.kernel.org, andreas.dilger@...el.com,
        Wang Shilong <wshilong@....com>
Subject: Re: [PATCH] ext4: add an interface to load block bitmaps

On Tue, May 15, 2018 at 10:06:23PM +0900, Wang Shilong wrote:
> From: Wang Shilong <wshilong@....com>
> 
> During our benchmarking, we found sometimes writing
> performances are not stable enough and there are some
> small read during write which could drop throughput(~30%).

Out of curiosity, what sort of benchmarks are you doing? 

>   It turned out that block bitmaps loading could make
> some latency here,also for a heavy fragmented filesystem,
> we might need load many bitmaps to find some free blocks.
> 
>   To improve above situation, we had a patch to load block
> bitmaps to memory and pin those bitmaps memory until umount
> or we release the memory on purpose, this could stable write
> performances and improve performances of a heavy fragmented
> filesystem.

This is true, but I wonder how realistic this is on real production
systems.  For a 1 TiB file system, pinning all of the block bitmaps
will require 32 megabytes of memory.  Is that really realistic for
your use case?

So is this something just for benchmarking (in which case what are you
trying to benchmark)?  Or is this something that you want to use in
production?  And if so, perhaps something to consider is analyzing how
fragmented and how full you want to run your file system.

Something to perhaps consider doing is storing the bitmap in memory in
a compressed form.  For example, you could use a run length encoding
scheme where 2 bytes is used to encoding the starting block of a free
extent, and 2 bytes to encode the length of the free extent.  For a
large number of mostly full (or mostly empty, for that matter) block
allocation bitmaps, this will be a much more efficient way to cache
the information in memory if you really want to keep all of the
allocation information in memory.

Something else to investigate is *why* is the file system getting so
fragmented in the first place, and are there things we can do to
prevent the file system from getting that fragmented in the first
place....

						- Ted