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  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]
Date:   Tue, 15 May 2018 22:58:10 -0400
From:   "Theodore Y. Ts'o" <>
To:     Wang Shilong <>
        Wang Shilong <>
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 <>
> 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

						- Ted

Powered by blists - more mailing lists