From: alex chen <alex.chen@huawei.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] ocfs2: add trimfs dlm lock
Date: Fri, 8 Dec 2017 09:13:37 +0800 [thread overview]
Message-ID: <5A29E741.8040802@huawei.com> (raw)
In-Reply-To: <5A29DE36020000F9001C5F44@prv-mh.provo.novell.com>
Hi Gang,
On 2017/12/8 8:35, Gang He wrote:
> Hello Andrew and All,
>
>>>> Andrew Morton <akpm@linux-foundation.org> 12/08/17 7:34 AM >>>
> On Thu, 7 Dec 2017 21:21:58 +0800 Gang He <ghe@suse.com> wrote:
>
>> As you know, ocfs2 has support trim the underlying disk via
>> fstrim command. But there is a problem, ocfs2 is a shared storage
>> cluster file system, if the user configures a scheduled fstrim
>> job on each file system node, this will trigger multiple nodes
>> trim a shared disk simultaneously, it is very wasteful for CPU
>> and IO consumption.
>> Then, we introduce a trimfs dlm lock, which will make only one
>> fstrim command is running on the shared disk among the cluster,
>> the other fstrim command should be returned with -EBUSY errno.
>
> Newly returning -EBUSY sounds a bit rude. And non-backward-compatible.
> Would it be better for the other fstrim callers to wait until the
> operation has completed then return success?
> Gang: OK, that means, if multiple nodes trim a shared disk simultaneously,
> only one node (get the lock first) do the real trimming operation,
> the other nodes will wait until that node finishes trimming, then return zero.
> Does anyone has more comments? If not, I will do this change in v2.
>
IMO, it is better for the other fstrim callers to wait until this node finishes trimming.
Thanks,
Alex
> Thanks
> Gang
>
>
>
>
>
> _______________________________________________
> Ocfs2-devel mailing list
> Ocfs2-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/ocfs2-devel
>
>
prev parent reply other threads:[~2017-12-08 1:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-07 13:21 [Ocfs2-devel] [PATCH] ocfs2: add trimfs dlm lock Gang He
2017-12-07 23:33 ` Andrew Morton
2017-12-08 0:35 ` Gang He
2017-12-08 1:13 ` alex chen [this message]
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=5A29E741.8040802@huawei.com \
--to=alex.chen@huawei.com \
--cc=ocfs2-devel@oss.oracle.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.