linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Namjae Jeon <linkinjeon@kernel.org>
To: Vincent <laivcf@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, Sungjong Seo <sj1557.seo@samsung.com>
Subject: Re: exfat: slow write performance
Date: Tue, 30 Jul 2024 11:32:11 +0900	[thread overview]
Message-ID: <CAKYAXd-X-dVRwNQweye46OrGFq5Hj0_yZV-dnComOFtJYMvpGQ@mail.gmail.com> (raw)
In-Reply-To: <CAEqW9OxJtbqvLHBKygW918tk=hS+ThqR79DmO-2qYp+V1FfqPQ@mail.gmail.com>

2024년 7월 29일 (월) 오후 11:47, Vincent <laivcf@gmail.com>님이 작성:
>
> I've found that write performance of exFAT is a lot lower than other
> filesystems on our setup with a fast NVMe SSD:
>
> - Kernel: 6.10.0-364.vanilla.fc40.x86_64
> - Test cmd: fio -name=fioWr -ioengine=libaio -directory=<mount point>
> -blocksize=1M -readwrite=write -filesize=10G -end_fsync=1 -numjobs=8
> -direct=1 -group_reporting
> - Benchmarks:
>     - exFAT: Direct I/O: ~1370 MiB/s (Buffered: ~1250 MiB/s)
> (mkfs.exfat -c 1M -b 1M <device>)
>     - ext4: Direct I/O: ~2230 MiB/s (Buffered: ~2150 MiB/s)
>     - xfs: Direct I/O: ~2220 MiB/s (Buffered: ~2200 MiB/s)
>
> I found that direct I/O is disabled for most of these writes in exFAT,
> code responsible is "exfat_direct_IO()" in "fs/exfat/inode.c". As the
> written file is being expanded it is falling back to normal buffered
> write. The relevant code also has the following FIXME comment
> (inherited from the fat driver):
>
> /*
> * FIXME: blockdev_direct_IO() doesn't use ->write_begin(),
> * so we need to update the ->i_size_aligned to block boundary.
> *
> * But we must fill the remaining area or hole by nul for
> * updating ->i_size_aligned
> *
> * Return 0, and fallback to normal buffered write.
> */
>
> I have tried working around this problem by preallocating the file. I
> see good write speeds in the direct I/O case (matching ext4 ~2200
> MiB/s, Buffered: ~1700 MiB/s), the problem is that preallocation is
> slow since native fallocate is not supported.
>
> What would the maintainers recommend as the best course of action for
> us here? I have noticed [1] that FALLOC_FL_KEEP_SIZE was implemented
> in fat, so perhaps that would be simple to work on first?
It is difficult to implement due to exfat on-disk layout constraints.
>
> Does anyone with more experience in the exFAT driver know the full
> reasons behind the direct I/O disabling, and what it would take to
> support direct I/O during file extension? Perhaps recent changes may
> have made fixing this simpler?
I suggest you try direct IO write after extending the file size you
want with ftruncate.
>
> Thanks.
>
> 1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/fat?id=b13bb33eacb7266d66a3adf03adaa0886d091789
>

      reply	other threads:[~2024-07-30  2:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29 14:33 exfat: slow write performance Vincent
2024-07-30  2:32 ` Namjae Jeon [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=CAKYAXd-X-dVRwNQweye46OrGFq5Hj0_yZV-dnComOFtJYMvpGQ@mail.gmail.com \
    --to=linkinjeon@kernel.org \
    --cc=laivcf@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sj1557.seo@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).