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;
MIME-Version: 1.0
References: <20201027132751.29858-1-jack@suse.cz> <CAO9xwp0AtCLG77g6fWgu9un9XPD3d5U6ZtjWc3FRJrB8NK44SQ@mail.gmail.com>
 <CAO9xwp3sSjzy9W8pMjV6vYitfZ9BmZE-9bLwcLg1uz3CFBHUcQ@mail.gmail.com> <20201120181030.GF609857@mit.edu>
In-Reply-To: <20201120181030.GF609857@mit.edu>
From:   Mauricio Faria de Oliveira <mfo@canonical.com>
Date:   Mon, 23 Nov 2020 20:52:29 -0300
Message-ID: <CAO9xwp1zQ6PD9u4sD-8Vbns8NNWG-x-8JodG-wwERjnct4_4wQ@mail.gmail.com>
Subject: Re: [PATCH] ext4: Fix mmap write protection for data=journal mode
To:     "Theodore Y. Ts'o" <tytso@mit.edu>
Cc:     Jan Kara <jack@suse.cz>, linux-ext4@vger.kernel.org,
        Andreas Dilger <adilger@dilger.ca>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hey Ted,

On Fri, Nov 20, 2020 at 3:10 PM Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> Mauricio,
>
> Thanks for your work in finding the corner cases for data=journal.  If

Thank you and Jan for your suggestions and guidance to fix them.

> you don't mind me asking, however --- what are the use cases for you
> where data=journal is the preferred mode for ext4?  There are a lot of
> advanced features for data=journal mode which don't work.  This
> includes things like dioread_nolock (now the default), delayed
> allocation, and other optimizations.
>
> It used to be that data=journal pretty nicely fell out of how ext4
> worked in "normally".  These days, data=journal is becoming more and
> more an exception case that requires special handling.  And to be
> honest, every so often there has been discussion about whether the
> maintenance overhead of data=journal has been worth keeping it.  So
> far, we just don't bother making data=journal work with things like
> delayed allocation, and one of ther reasons why we've kept it around
> is because it's a unique mode that none of the Linux file systems
> have.
>
> It would be useful, though, to understand what are the use cases where
> you (or your customers) are finding data=journal useful, so we can
> better optimize for their use case.  And if there are enough people
> who care about it --- and clearly, you've invested so much effort that
> you definitely fall into that category :-) --- then maybe there's a
> business case for investing more into data=journal and trying to make
> it something which is easier to maintain and can work with things like
> delayed allocation.
>

The main reason a customer used data=journal in some cases
is it provided them more consistency w/ data on power loss.

Specifically, it prevented some consistency check errors on
applications in which it's unfortunately not always possible
to request/guarantee that sync() is called (not ext4's fault.)

We've previously exposed the disadvantages with data=journal,
including the discussion about its future/maintenance upstream
and associated risks with less exposure/testing (eg, this bug! :)
in order to assist them with decision-making and maybe switching.

It seems that data=ordered with nodelalloc and a smaller commit=
interval could help them, but that's going on experiment stages.

So, it seems this use case is more about data integrity than features,
and data=journal does seem to help with that despite the applications.

Glad that ext4 still provides such mode; but it's understandable that
maintenance and features and special handling leads to the discussion
about no longer keeping it.

Thanks for reaching out to understand the use cases from users,
and being willing to consider that into development/maintenance.

There's also a few bits about it from Andreas in the v1 series [1].

Hope this helps!
Mauricio

[1] https://lore.kernel.org/linux-ext4/C9FEDED5-CDEE-449F-AE11-64BB56A42277@dilger.ca/

> Thanks,
>
>                                         - Ted


-- 
Mauricio Faria de Oliveira