Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Subject: Re: [PATCH v2] mmp: do not use O_DIRECT when working with regular
 file
From:   Alexey Lyashkov <alexey.lyashkov@gmail.com>
In-Reply-To: <YC/k7YhZNxO7O5PF@mit.edu>
Date:   Sat, 20 Feb 2021 16:21:13 +0300
Cc:     Lukas Czerner <lczerner@redhat.com>,
        Andreas Dilger <adilger@dilger.ca>,
        Artem Blagodarenko <artem.blagodarenko@gmail.com>,
        linux-ext4 <linux-ext4@vger.kernel.org>,
        Eric Sandeen <sandeen@redhat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FEFE06F0-36C5-4E5B-AD65-3709DEB8E5F2@gmail.com>
References: <20210212093719.162065-1-lczerner@redhat.com>
 <20210218095146.265302-1-lczerner@redhat.com>
 <BF8274AF-A9C6-40F4-8B99-FEBA82878C36@dilger.ca>
 <99A17D19-8764-4027-8B1E-E7ADBE5E2CEE@gmail.com>
 <20210219105713.uu2mywenytfd2e5j@work>
 <E16FB371-5DFC-4A10-A9E2-36541FCF7D30@gmail.com>
 <20210219133459.vezgrlkjpmaizvb4@work>
 <BB31D81D-F4A9-490E-8F9D-2BC6350CE6B0@gmail.com> <YC/k7YhZNxO7O5PF@mit.edu>
To:     Theodore Ts'o <tytso@mit.edu>
Precedence: bulk

Teodore,

this important because of some points.
metadata for the large devices (>400T without bigalloc enabled) very =
large.=20
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=E2=80=99t think half of them is useful.


> 19 =D1=84=D0=B5=D0=B2=D1=80. 2021 =D0=B3., =D0=B2 19:18, Theodore Ts'o =
<tytso@mit.edu> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):
>=20
> Alexey,
>=20
> 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 !=3D page size is rare as well.  The main use cases I
> know of fs blocksize !=3D 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.
>=20
As i point early - e2fsprogs _FORCE_ a 1k block size in some places.
Like
blk64_t ext2fs_first_backup_sb(blk64_t *superblock, unsigned int =
*block_size,
..
        for (try_blocksize =3D EXT2_MIN_BLOCK_SIZE;
             try_blocksize <=3D EXT2_MAX_BLOCK_SIZE ; try_blocksize *=3D =
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 =3D=3D 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=C2=BB.)
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?

>=20
> 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?
>=20
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=E2=80=99t need to be supported - lets drop =
this code, instead of have this completely broken now.


Thanks,=20
Alex.

> Thanks,
>=20
> 						- Ted