All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Ashlie Martinez <ashmrtn@utexas.edu>
Cc: Vijay Chidambaram <vvijay03@gmail.com>,
	Ext4 <linux-ext4@vger.kernel.org>
Subject: Re: ext4 fix for interaction between i_size, fallocate, and delalloc after a crash
Date: Mon, 27 Nov 2017 11:11:38 -0500	[thread overview]
Message-ID: <20171127161137.4ghjcxfklpurk2eo@thunk.org> (raw)
In-Reply-To: <CAFk8rvZ=EAUcAzxgi4bk+Qh2Y3ACZEv8unaowi0jvPNRB97XMA@mail.gmail.com>

On Mon, Nov 27, 2017 at 08:31:07AM -0600, Ashlie Martinez wrote:
> Ted,
> 
> Thank you very much for taking the time to lay all of this out for me
> (and throwing some humor and youtube links to boot), despite how busy
> you were (I hope everything is alright!). I see now why the fix works
> and what was going wrong. It appears I was confused about the order of
> operations being performed in the test based on what I read in another
> email. I believe in another email somewhere I read that the fallocate
> was before a delayed write so I was thinking something like fallocate
> then write. I see now that it is write with delayed allocation
> (resolved after fallocate) and then fallocate. With that piece of
> information everything else about the test, delayed allocation, and
> the fix make sense.

Sorry, "before" was misleading.  When I used the word "before", I was
speaking of the order that the operations hit the disk.  The confusion
comes from the fact that the delayed allocation write was *issued*
before the fallocate, but in terms of when they are committed to disk,
the fallocate commits *first*, and then 25-30 seconds later, the
delayed allocation write is resolved and then committed to disk.

It's the difference between the order that the operations are issued
and when they are committed to disk which is what caused the bug; and
the problem reproduction relies on crashing/aborting the file system
between the time that the two operations would have been committed.

Hopefully this will be helpful in terms of finding a way to create
automated file system testing systems that can detect bugs similar to
this one.  I can imagine that if you ever want to extend this to
database testing, a similar technique might be used to detect
transactions which close in a different order than how they were
issued, or dealing transactions which end up getting rolled back.

						- Ted

P.S.  I see you have some Google internships under your belt, so I'm
sure you know the drill, but I hope you'll consider us for another
future internship experience.   :-)

  reply	other threads:[~2017-11-27 16:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 15:43 ext4 fix for interaction between i_size, fallocate, and delalloc after a crash Ashlie Martinez
2017-11-21 16:17 ` Ashlie Martinez
2017-11-22 18:03 ` Theodore Ts'o
2017-11-23  5:39   ` Amir Goldstein
2017-11-27 14:31   ` Ashlie Martinez
2017-11-27 16:11     ` Theodore Ts'o [this message]
2017-11-28 13:04       ` Ashlie Martinez
2017-11-28 20:45         ` Theodore Ts'o
2017-11-28 21:27           ` Ashlie Martinez
2017-11-29  3:37             ` Amir Goldstein
2017-11-29  6:13             ` Theodore Ts'o
2017-11-29  8:07               ` Amir Goldstein
2017-11-29 19:58                 ` Ashlie Martinez
2017-11-30  0:48                   ` Theodore Ts'o
2017-11-30  1:46                     ` Ashlie Martinez
2017-11-30  4:46                       ` Theodore Ts'o
2017-11-30 14:22                         ` Theodore Ts'o
2017-11-30 14:51                         ` Ashlie Martinez
2017-11-30 15:27                           ` Theodore Ts'o
2017-11-30 15:40                             ` Ashlie Martinez
2017-12-02 20:00                               ` Ashlie Martinez
2017-11-30  0:24                 ` Theodore Ts'o
2017-11-30  6:46                   ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171127161137.4ghjcxfklpurk2eo@thunk.org \
    --to=tytso@mit.edu \
    --cc=ashmrtn@utexas.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=vvijay03@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.