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  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]
Date:   Fri, 05 Jul 2019 09:25:48 -0700
From:   James Bottomley <>
To:     Theodore Ts'o <>
        Parisc List <>
Subject: Question about ext4 testing: need to produce a high depth extent
 tree to verify mapping code

I've got preliminary ext4 support for palo completed.  My original plan
was to switch our boot loader (iplboot) to using libext2fs, but that
proved to be impossible due to the external dependencies libext2fs
needs which we simply can't provide in a tiny bootloader, so I switched
to simply adding support for variable sized groups and handling extent
based files in our original code.  Right at the moment we only support
reading files for the kernel and the initrd, so we have a simple
routine that loads blocks monotonically by mapping from inode relative
to partition absolute.  It's fairly simple to cache the extent tree at
all depths and use a similar resolution scheme for extent based
filesystems.  I'll add this list on cc to the initial patch so you can
check it.

Now the problem: I'd like to do some testing with high depth extent
trees to make sure I got this right, but the files we load at boot are
~20MB in size and I'm having a hard time fragmenting the filesystem
enough to produce a reasonable extent (I've basically only got to a two
level tree with two entries at the top).  Is there an easy way of
producing a high depth extent tree for a 20MB file?



Powered by blists - more mailing lists