From: Martin Bukatovic <martin.bukatovic@gmail.com>
To: fio@vger.kernel.org
Subject: [PATCH v3] Make fill_device to stop writing on EDQUOT
Date: Tue, 11 May 2021 09:38:55 +0200 [thread overview]
Message-ID: <YJo0j+luAzHGFWQ+@dione.lan> (raw)
Option fill_device stops writing when we run out of quota as well.
Signed-off-by: Martin Bukatovic <martin.bukatovic@gmail.com>
---
Changes in v3:
- fixing code style
Changes in v2:
- moved ENOSPC check into ENOSPC check, modified the log statement
---
HOWTO | 3 ++-
backend.c | 7 ++++---
filesetup.c | 11 ++++++++---
fio.1 | 3 ++-
4 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/HOWTO b/HOWTO
index 889526d9..6bc52fb1 100644
--- a/HOWTO
+++ b/HOWTO
@@ -1852,7 +1852,8 @@ I/O size
.. option:: fill_device=bool, fill_fs=bool
Sets size to something really large and waits for ENOSPC (no space left on
- device) as the terminating condition. Only makes sense with sequential
+ device) or EDQUOT (disk quota exceeded)
+ as the terminating condition. Only makes sense with sequential
write. For a read workload, the mount point will be filled first then I/O
started on the result. This option doesn't make sense if operating on a raw
device node, since the size of that is already known by the file system.
diff --git a/backend.c b/backend.c
index 399c299e..6290e0d6 100644
--- a/backend.c
+++ b/backend.c
@@ -393,7 +393,7 @@ static bool break_on_this_error(struct thread_data *td, enum fio_ddir ddir,
td_clear_error(td);
*retptr = 0;
return false;
- } else if (td->o.fill_device && err == ENOSPC) {
+ } else if (td->o.fill_device && (err == ENOSPC || err == EDQUOT)) {
/*
* We expect to hit this error if
* fill_device option is set.
@@ -1105,7 +1105,7 @@ reap:
if (td->trim_entries)
log_err("fio: %lu trim entries leaked?\n", td->trim_entries);
- if (td->o.fill_device && td->error == ENOSPC) {
+ if (td->o.fill_device && (td->error == ENOSPC || td->error == EDQUOT)) {
td->error = 0;
fio_mark_td_terminate(td);
}
@@ -1120,7 +1120,8 @@ reap:
if (i) {
ret = io_u_queued_complete(td, i);
- if (td->o.fill_device && td->error == ENOSPC)
+ if (td->o.fill_device &&
+ (td->error == ENOSPC || td->error == EDQUOT))
td->error = 0;
}
diff --git a/filesetup.c b/filesetup.c
index e664f8b4..296de5a1 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -226,11 +226,16 @@ static int extend_file(struct thread_data *td, struct fio_file *f)
if (r < 0) {
int __e = errno;
- if (__e == ENOSPC) {
+ if (__e == ENOSPC || __e == EDQUOT) {
+ const char *__e_name;
if (td->o.fill_device)
break;
- log_info("fio: ENOSPC on laying out "
- "file, stopping\n");
+ if (__e == ENOSPC)
+ __e_name = "ENOSPC";
+ else
+ __e_name = "EDQUOT";
+ log_info("fio: %s on laying out "
+ "file, stopping\n", __e_name);
}
td_verror(td, errno, "write");
} else
diff --git a/fio.1 b/fio.1
index c3916168..75c06bf3 100644
--- a/fio.1
+++ b/fio.1
@@ -1638,7 +1638,8 @@ of a file. This option is ignored on non-regular files.
.TP
.BI fill_device \fR=\fPbool "\fR,\fB fill_fs" \fR=\fPbool
Sets size to something really large and waits for ENOSPC (no space left on
-device) as the terminating condition. Only makes sense with sequential
+device) or EDQUOT (disk quota exceeded)
+as the terminating condition. Only makes sense with sequential
write. For a read workload, the mount point will be filled first then I/O
started on the result. This option doesn't make sense if operating on a raw
device node, since the size of that is already known by the file system.
--
2.30.2
--
Martin Bukatovič
next reply other threads:[~2021-05-11 7:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-11 7:38 Martin Bukatovic [this message]
2021-05-11 13:45 ` [PATCH v3] Make fill_device to stop writing on EDQUOT Jens Axboe
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=YJo0j+luAzHGFWQ+@dione.lan \
--to=martin.bukatovic@gmail.com \
--cc=fio@vger.kernel.org \
/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.