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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Sat, 20 Feb 2021 16:21:13 +0300
From:   Alexey Lyashkov <>
To:     Theodore Ts'o <>
Cc:     Lukas Czerner <>,
        Andreas Dilger <>,
        Artem Blagodarenko <>,
        linux-ext4 <>,
        Eric Sandeen <>
Subject: Re: [PATCH v2] mmp: do not use O_DIRECT when working with regular


this important because of some points.
metadata for the large devices (>400T without bigalloc enabled) very large. 
Once buffered IO enabled this generate a very large memory consumption.
(12G+ for metadata itself in page cache, and 12G+ for user memory).
I don’t think half of them is useful.

> 19 февр. 2021 г., в 19:18, Theodore Ts'o <> написал(а):
> Alexey,
> It'd be helpful to me to understand _why_ this use case is important
> for your workloads.  O_DIRECT support is rarely used as far as I know,
> and fs blocksize != page size is rare as well.  The main use cases I
> know of fs blocksize != page size is on architectures (not terribly
> common) with 16k or 64k page sizes, that want to use 4k file system
> blocksizes for interoperability reasons.
As i point early - e2fsprogs _FORCE_ a 1k block size in some places.
blk64_t ext2fs_first_backup_sb(blk64_t *superblock, unsigned int *block_size,
        for (try_blocksize = EXT2_MIN_BLOCK_SIZE;
             try_blocksize <= EXT2_MAX_BLOCK_SIZE ; try_blocksize *= 2) {
errcode_t ext2fs_open2(const char *name, const char *io_options,
                io_channel_set_blksize(fs->io, SUPERBLOCK_OFFSET);

both cases will generate unliagned (from block device view) access.
Without any idea which a block size is in real.

> (And I suppose because mke2fs uses a 4k block size by default.  Perhaps
> we should change this so that the default is that mke2fs will use a
> block size == page size, unless for some reason the page size is not
> one supported by ext4 (although I'm not aware of any architecture
> wanting page sizes > 64k), or the user explicitly specifies the block
> size using "mke2fs -b».)
Nice. AARCH64 / RHEL8 - is 64k page, so what about interoperability?
Should AARCH64 able to read devices which created on x86_64 with 4k page size?

> Are you trying to make O_DIRECT support in e2fsprogs a first class
> reason out of completeness concern?  Or is this a use case which is
> important in production workloads that you are familiar with?
primary goal - debugfs -D / e2image - both in production on large storages.
I looking to the e2fsck because of large memory consumption.

If you think O_DIRECT don’t need to be supported - lets drop this code, instead of have this completely broken now.


> Thanks,
> 						- Ted

Powered by blists - more mailing lists