All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Perepechko <anserper@yandex.ru>
To: Wang Shilong <wangshilong1991@gmail.com>
Cc: Shuichi Ihara <sihara@ddn.com>, Wang Shilong <wshilong@ddn.com>,
	Li Xi <lixi@ddn.com>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org
Subject: Re: quota: dqio_mutex design
Date: Thu, 03 Aug 2017 16:55:40 +0300	[thread overview]
Message-ID: <8209641.NLfoyJy6gT@panda> (raw)
In-Reply-To: <2768942.M4bvsTtnaB@panda>

Let me put it this way:

Under file creation from different threads, ext4 will generate a series of
dquot updates (incore and then ondisk, through journal):

dquot update1
dquot update2
dquot update3
...
dquot updateN

Either with my patch or without it, ondisk dquot update through journal
may miss dquot update1, dquot update2, ... dquot update{N-1}.

You can easily see that from the code of dquot_commit():

int dquot_commit(struct dquot *dquot)
{
        int ret = 0;
        struct quota_info *dqopt = sb_dqopt(dquot->dq_sb);

        mutex_lock(&dqopt->dqio_mutex);
        spin_lock(&dq_list_lock);
        if (!clear_dquot_dirty(dquot)) {
                spin_unlock(&dq_list_lock);
                goto out_sem;
        }
...
}


If actual dquot_commit() wrote dquot update N, the threads commiting
updates 1 through N-1 will exit immediately once they get dqio_mutex
since the dquot will NOT be dirty.

My patch only avoids blocking on dqio_mutex when we know for sure
that another will NECESSARILY write the needed or a FRESHER dquot ondisk.

> > This change mean if this dquot is dirty we skip, this
> > won't work because in this way, quota update is only kept in vfs dquota
> > memory and newer update is not wrote to journal file and not wrapped into
> > transaction too.
> 
> That's not true.
> 
> As I explained earlier, having DQ_MOD_B set at this point means another
> thread is going to write dquot but hasn't yet started doing so. This thread
> does not care whether it updates the ondisk dquot with its own data or with
> fresher data which came from another thread. In-core dquot has no indication
> of whose data in contains.
> 
> As I also explained earlier, the update cannot happen in the context of
> another transaction because thread A which sees DQ_MOD_B set and thread
> B which is running dquot_commit() both have journal handles to the same
> transaction. There's only one running transaction at a time and thread B
> does not switch to another transaction.
> 
> Please read the code carefully.
> 
> > This is not what journal quota means to do.
> > 
> > 
> > Thanks,
> > Shilong
> > 
> > > Thank you,
> > > Andrew

  reply	other threads:[~2017-08-03 13:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 12:23 quota: dqio_mutex design Andrew Perepechko
2017-03-03 10:08 ` Jan Kara
2017-03-09 22:29   ` Andrew Perepechko
2017-03-13  8:44     ` Jan Kara
2017-06-21 10:52   ` Jan Kara
     [not found]     ` <4181747.CBilgxvOab@panda>
2017-08-01 13:02       ` Jan Kara
2017-08-02 16:25         ` Jan Kara
2017-08-02 17:52           ` Andrew Perepechko
2017-08-03 11:09             ` Jan Kara
2017-08-03 11:31             ` Wang Shilong
2017-08-03 12:24               ` Andrew Perepechko
2017-08-03 13:19                 ` Wang Shilong
2017-08-03 13:41                   ` Andrew Perepechko
2017-08-03 13:55                     ` Andrew Perepechko [this message]
2017-08-03 14:23                       ` Jan Kara
2017-08-03 14:36               ` Jan Kara
2017-08-03 14:39                 ` Wang Shilong
2017-08-08 16:06                   ` Jan Kara
2017-08-14  3:24                     ` Wang Shilong
2017-08-14  3:28                       ` Wang Shilong
2017-08-14  3:53                       ` Wang Shilong
2017-08-14  8:22                         ` Jan Kara

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=8209641.NLfoyJy6gT@panda \
    --to=anserper@yandex.ru \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lixi@ddn.com \
    --cc=sihara@ddn.com \
    --cc=wangshilong1991@gmail.com \
    --cc=wshilong@ddn.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.