* linux /dev and normal files
@ 2014-09-30 23:49 Elliott, Robert (Server Storage)
2014-10-01 1:02 ` Jens Axboe
0 siblings, 1 reply; 19+ messages in thread
From: Elliott, Robert (Server Storage) @ 2014-09-30 23:49 UTC (permalink / raw)
To: Jens Axboe, fio@vger.kernel.org; +Cc: Sitsofe Wheeler, Jon Tango
> -----Original Message-----
> From: fio-owner@vger.kernel.org [mailto:fio-owner@vger.kernel.org] On Behalf
> Of Sitsofe Wheeler
...
> filename=\\.\physicaldrive1
> ioengine=windowsaio
> direct=1
...
> size=86%
> bs=4k
...
I noticed that, in linux, if you select
filename=/dev/sd<not there>
size=<something>
(e.g., if you run fio after a device has failed), it creates a
normal file of the specified size (which could be quite large
if using a script such as above).
If you use direct=1, the file is created, followed by this error:
fio: pid=8914, err=22/file:filesetup.c:611, func=open(/dev/sdad), error=Invalid argument
fio: looks like your file system does not support direct=1/buffered=0
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT
If you don't use size=, no file is created and this error
occurs:
fio: pid=0, err=22/file:filesetup.c:820, func=total_file_size, error=Invalid argument
drive_ag: you need to specify size=
If you recreate the device, udevd blows away any such file with
the block device node file, so it's not a good place to put
normal files, even if that is intentional.
In Windows, all "\\.\" paths are assumed to mean block devices,
so fio doesn't inadvertently try to create a normal file in
such a location.
Should fio treat "/dev" paths in linux the same way?
---
Rob Elliott HP Server Storage
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-09-30 23:49 linux /dev and normal files Elliott, Robert (Server Storage)
@ 2014-10-01 1:02 ` Jens Axboe
2014-10-01 1:12 ` Elliott, Robert (Server Storage)
0 siblings, 1 reply; 19+ messages in thread
From: Jens Axboe @ 2014-10-01 1:02 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
On 2014-09-30 17:49, Elliott, Robert (Server Storage) wrote:
>
>> -----Original Message-----
>> From: fio-owner@vger.kernel.org [mailto:fio-owner@vger.kernel.org] On Behalf
>> Of Sitsofe Wheeler
> ...
>> filename=\\.\physicaldrive1
>> ioengine=windowsaio
>> direct=1
> ...
>> size=86%
>> bs=4k
> ...
>
> I noticed that, in linux, if you select
> filename=/dev/sd<not there>
> size=<something>
>
> (e.g., if you run fio after a device has failed), it creates a
> normal file of the specified size (which could be quite large
> if using a script such as above).
>
> If you use direct=1, the file is created, followed by this error:
> fio: pid=8914, err=22/file:filesetup.c:611, func=open(/dev/sdad), error=Invalid argument
> fio: looks like your file system does not support direct=1/buffered=0
> fio: looks like your file system does not support direct=1/buffered=0
> fio: destination does not support O_DIRECT
This is because /dev is usually devtmpfs these days, and that fs does
not support O_DIRECT.
> If you don't use size=, no file is created and this error
> occurs:
> fio: pid=0, err=22/file:filesetup.c:820, func=total_file_size, error=Invalid argument
> drive_ag: you need to specify size=
>
> If you recreate the device, udevd blows away any such file with
> the block device node file, so it's not a good place to put
> normal files, even if that is intentional.
>
> In Windows, all "\\.\" paths are assumed to mean block devices,
> so fio doesn't inadvertently try to create a normal file in
> such a location.
>
> Should fio treat "/dev" paths in linux the same way?
No, I don't think so. It's a directory like anything else. Who knows
what will happen in the future, with all the core OS changes in Linux.
/dev could be a symlink, or special files could be in a different
location completely. What about FreeBSD, should we do the same there?
Or Solaris?
I'd much rather keep fio ignorant of any "special" directories, even if
it means that sometimes you do potentially run into issues like the
above, where you specify a block device that does not exist.
--
Jens Axboe
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: linux /dev and normal files
2014-10-01 1:02 ` Jens Axboe
@ 2014-10-01 1:12 ` Elliott, Robert (Server Storage)
2014-10-01 1:17 ` Jens Axboe
0 siblings, 1 reply; 19+ messages in thread
From: Elliott, Robert (Server Storage) @ 2014-10-01 1:12 UTC (permalink / raw)
To: Jens Axboe, fio@vger.kernel.org; +Cc: Sitsofe Wheeler, Jon Tango
> -----Original Message-----
> From: Jens Axboe [mailto:axboe@kernel.dk]
...
> I'd much rather keep fio ignorant of any "special" directories, even if
> it means that sometimes you do potentially run into issues like the
> above, where you specify a block device that does not exist.
How about an option in the script:
direct=2 file must exist and be a block device, otherwise skip it
If the size is too big, this is the error:
drive_r: Laying out IO file(s) (1 file(s) / 1572864000MB)
fio: posix_fallocate fails: No space left on device
fio: ENOSPC on laying out file, stopping
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT
fio: pid=8991, err=22/file:filesetup.c:611, func=open(/dev/sdnothere), error=Invalid argument
fio: pid=8990, err=22/file:filesetup.c:611, func=open(/dev/sdnothere), error=Invalid argument
and it leaves a "file" that looks like:
$ ls -alt /dev/sd*
-rw-r--r-- 1 root root 1649267441664000 Sep 30 20:10 /dev/sdnothere
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-10-01 1:12 ` Elliott, Robert (Server Storage)
@ 2014-10-01 1:17 ` Jens Axboe
2014-10-01 3:43 ` Jens Axboe
0 siblings, 1 reply; 19+ messages in thread
From: Jens Axboe @ 2014-10-01 1:17 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
On 2014-09-30 19:12, Elliott, Robert (Server Storage) wrote:
>
>
>> -----Original Message-----
>> From: Jens Axboe [mailto:axboe@kernel.dk]
> ...
>> I'd much rather keep fio ignorant of any "special" directories, even if
>> it means that sometimes you do potentially run into issues like the
>> above, where you specify a block device that does not exist.
>
> How about an option in the script:
> direct=2 file must exist and be a block device, otherwise skip it
Might be a bit nasty to overload direct= like that. But I'd be open to
adding an option that says must_be_bdev or something, which can be a
bool as well.
> If the size is too big, this is the error:
>
> drive_r: Laying out IO file(s) (1 file(s) / 1572864000MB)
> fio: posix_fallocate fails: No space left on device
>
> fio: ENOSPC on laying out file, stopping
> fio: looks like your file system does not support direct=1/buffered=0
> fio: destination does not support O_DIRECT
> fio: looks like your file system does not support direct=1/buffered=0
> fio: destination does not support O_DIRECT
> fio: pid=8991, err=22/file:filesetup.c:611, func=open(/dev/sdnothere), error=Invalid argument
> fio: pid=8990, err=22/file:filesetup.c:611, func=open(/dev/sdnothere), error=Invalid argument
>
> and it leaves a "file" that looks like:
>
> $ ls -alt /dev/sd*
> -rw-r--r-- 1 root root 1649267441664000 Sep 30 20:10 /dev/sdnothere
Yeah I know, I've had that happen myself 1-2 times.
--
Jens Axboe
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-10-01 1:17 ` Jens Axboe
@ 2014-10-01 3:43 ` Jens Axboe
2014-10-01 7:36 ` Sitsofe Wheeler
2014-10-01 23:52 ` Elliott, Robert (Server Storage)
0 siblings, 2 replies; 19+ messages in thread
From: Jens Axboe @ 2014-10-01 3:43 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
On 2014-09-30 19:17, Jens Axboe wrote:
> On 2014-09-30 19:12, Elliott, Robert (Server Storage) wrote:
>>
>>
>>> -----Original Message-----
>>> From: Jens Axboe [mailto:axboe@kernel.dk]
>> ...
>>> I'd much rather keep fio ignorant of any "special" directories, even if
>>> it means that sometimes you do potentially run into issues like the
>>> above, where you specify a block device that does not exist.
>>
>> How about an option in the script:
>> direct=2 file must exist and be a block device, otherwise skip it
>
> Might be a bit nasty to overload direct= like that. But I'd be open to
> adding an option that says must_be_bdev or something, which can be a
> bool as well.
Totally untested patch attached (it compiles). There's a new option,
filetype. If not set, if will allow any file type. Can be set to:
any default, allow any file type
file regular file
bdev block device
chardev character device
pipe pipe
So for your case, you'd set
filetype=bdev
and you'd avoid the issue. Note that it only works for files specified
with filename=. Any other way of adding a file (blktrace replay,
opendir=, or fio added files when no filename= given) will ignore the
filetype setting.
--
Jens Axboe
[-- Attachment #2: filetype.patch --]
[-- Type: text/x-patch, Size: 7871 bytes --]
diff --git a/cconv.c b/cconv.c
index 4a40ed0d647b..61867625282a 100644
--- a/cconv.c
+++ b/cconv.c
@@ -69,6 +69,7 @@ void convert_thread_options_to_cpu(struct thread_options *o,
string_to_cpu(&o->profile, top->profile);
string_to_cpu(&o->cgroup, top->cgroup);
+ o->filetype = le32_to_cpu(top->filetype);
o->td_ddir = le32_to_cpu(top->td_ddir);
o->rw_seq = le32_to_cpu(top->rw_seq);
o->kb_base = le32_to_cpu(top->kb_base);
@@ -278,6 +279,7 @@ void convert_thread_options_to_net(struct thread_options_pack *top,
string_to_net(top->profile, o->profile);
string_to_net(top->cgroup, o->cgroup);
+ top->filetype = cpu_to_le32(o->filetype);
top->td_ddir = cpu_to_le32(o->td_ddir);
top->rw_seq = cpu_to_le32(o->rw_seq);
top->kb_base = cpu_to_le32(o->kb_base);
diff --git a/engines/net.c b/engines/net.c
index 8087207e505b..9ed4660d77b7 100644
--- a/engines/net.c
+++ b/engines/net.c
@@ -1194,7 +1194,7 @@ static int fio_netio_setup(struct thread_data *td)
struct netio_data *nd;
if (!td->files_index) {
- add_file(td, td->o.filename ?: "net", 0, 0);
+ add_file(td, td->o.filename ?: "net", 0, 0, 0);
td->o.nr_files = td->o.nr_files ?: 1;
td->o.open_files++;
}
diff --git a/engines/rbd.c b/engines/rbd.c
index 6fe87b8d010c..9b28c9f099ad 100644
--- a/engines/rbd.c
+++ b/engines/rbd.c
@@ -407,7 +407,7 @@ static int fio_rbd_setup(struct thread_data *td)
* The size of the RBD is set instead of a artificial file.
*/
if (!td->files_index) {
- add_file(td, td->o.filename ? : "rbd", 0, 0);
+ add_file(td, td->o.filename ? : "rbd", 0, 0, 0);
td->o.nr_files = td->o.nr_files ? : 1;
td->o.open_files++;
}
diff --git a/file.h b/file.h
index add77730fdb4..fd35ef7ef07e 100644
--- a/file.h
+++ b/file.h
@@ -13,12 +13,24 @@
* The type of object we are working on
*/
enum fio_filetype {
- FIO_TYPE_FILE = 1, /* plain file */
+ FIO_TYPE_ANY = 0,
+ FIO_TYPE_FILE, /* plain file */
FIO_TYPE_BD, /* block device */
FIO_TYPE_CHAR, /* character device */
FIO_TYPE_PIPE, /* pipe */
+ FIO_TYPE_END,
};
+static inline const char *file_type_name(int type)
+{
+ static const char *name[] = { "any", "file", "bdev", "chardev", "pipe", };
+
+ if (type < FIO_TYPE_END)
+ return name[type];
+
+ return "invalid";
+}
+
enum fio_file_flags {
FIO_FILE_open = 1 << 0, /* file is open */
FIO_FILE_closing = 1 << 1, /* file being closed */
@@ -167,7 +179,7 @@ extern int __must_check generic_close_file(struct thread_data *, struct fio_file
extern int __must_check generic_get_file_size(struct thread_data *, struct fio_file *);
extern int __must_check file_lookup_open(struct fio_file *f, int flags);
extern int __must_check pre_read_files(struct thread_data *);
-extern int add_file(struct thread_data *, const char *, int, int);
+extern int add_file(struct thread_data *, const char *, int, int, int);
extern int add_file_exclusive(struct thread_data *, const char *);
extern void get_file(struct fio_file *);
extern int __must_check put_file(struct thread_data *, struct fio_file *);
diff --git a/filesetup.c b/filesetup.c
index 43146ba7671f..f621813bb138 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -1241,7 +1241,8 @@ static struct fio_file *alloc_new_file(struct thread_data *td)
return f;
}
-int add_file(struct thread_data *td, const char *fname, int numjob, int inc)
+int add_file(struct thread_data *td, const char *fname, int numjob, int inc,
+ int check_type)
{
int cur_files = td->files_index;
char file_name[PATH_MAX];
@@ -1298,6 +1299,18 @@ int add_file(struct thread_data *td, const char *fname, int numjob, int inc)
get_file_type(f);
+ if (td->o.filetype != FIO_TYPE_ANY && f->filetype != td->o.filetype &&
+ check_type) {
+ sfree(f->file_name);
+ td->files[cur_files] = NULL;
+ sfree(f);
+ log_err("fio: dropping file '%s' of wrong type\n", file_name);
+ log_err("fio: wanted %s, got %s\n",
+ file_type_name(td->o.filetype),
+ file_type_name(f->filetype));
+ return -1;
+ }
+
switch (td->o.file_lock_mode) {
case FILE_LOCK_NONE:
break;
@@ -1337,7 +1350,7 @@ int add_file_exclusive(struct thread_data *td, const char *fname)
return i;
}
- return add_file(td, fname, 0, 1);
+ return add_file(td, fname, 0, 1, 0);
}
void get_file(struct fio_file *f)
@@ -1450,7 +1463,7 @@ static int recurse_dir(struct thread_data *td, const char *dirname)
}
if (S_ISREG(sb.st_mode)) {
- add_file(td, full_path, 0, 1);
+ add_file(td, full_path, 0, 1, 0);
continue;
}
if (!S_ISDIR(sb.st_mode))
diff --git a/init.c b/init.c
index e20845163279..d96154c1ceaf 100644
--- a/init.c
+++ b/init.c
@@ -1110,10 +1110,16 @@ static int add_job(struct thread_data *td, const char *jobname, int job_add_num,
file_alloced = 1;
if (o->nr_files == 1 && exists_and_not_file(jobname))
- add_file(td, jobname, job_add_num, 0);
+ add_file(td, jobname, job_add_num, 0, 0);
else {
- for (i = 0; i < o->nr_files; i++)
- add_file(td, make_filename(fname, sizeof(fname), o, jobname, job_add_num, i), job_add_num, 0);
+ for (i = 0; i < o->nr_files; i++) {
+ char *name;
+
+ name = make_filename(fname, sizeof(fname),
+ o, jobname,
+ job_add_num, i);
+ add_file(td, name, job_add_num, 0, 0);
+ }
}
}
diff --git a/iolog.c b/iolog.c
index 4a7d939af251..9c9ff3788c70 100644
--- a/iolog.c
+++ b/iolog.c
@@ -356,7 +356,7 @@ static int read_iolog2(struct thread_data *td, FILE *f)
} else if (r == 2) {
rw = DDIR_INVAL;
if (!strcmp(act, "add")) {
- fileno = add_file(td, fname, 0, 1);
+ fileno = add_file(td, fname, 0, 1, 0);
file_action = FIO_LOG_ADD_FILE;
continue;
} else if (!strcmp(act, "open")) {
diff --git a/options.c b/options.c
index 918de8e8e34b..7ddbf2793a1d 100644
--- a/options.c
+++ b/options.c
@@ -850,6 +850,7 @@ static int str_filename_cb(void *data, const char *input)
{
struct thread_data *td = data;
char *fname, *str, *p;
+ int bad, good;
p = str = strdup(input);
@@ -859,13 +860,22 @@ static int str_filename_cb(void *data, const char *input)
if (!td->files_index)
td->o.nr_files = 0;
+ good = bad = 0;
while ((fname = get_next_name(&str)) != NULL) {
if (!strlen(fname))
break;
- add_file(td, fname, 0, 1);
+ if (add_file(td, fname, 0, 1, 1) != -1) {
+ good++;
+ continue;
+ }
+ bad++;
}
free(p);
+
+ if (bad && !good)
+ return 1;
+
return 0;
}
@@ -1359,6 +1369,39 @@ struct fio_option fio_options[FIO_MAX_OPTS] = {
.group = FIO_OPT_G_FILENAME,
},
{
+ .name = "filetype",
+ .type = FIO_OPT_STR,
+ .off1 = td_var_offset(filetype),
+ .help = "File must match this filetype",
+ .def = "any",
+ .category = FIO_OPT_C_FILE,
+ .group = FIO_OPT_G_FILENAME,
+ .posval = {
+ { .ival = "any",
+ .oval = FIO_TYPE_ANY,
+ .help = "Any filetype",
+ },
+ { .ival = "file",
+ .oval = FIO_TYPE_FILE,
+ .help = "Regular file",
+ },
+ { .ival = "bdev",
+ .oval = FIO_TYPE_BD,
+ .help = "Block device",
+ },
+ {
+ .ival = "chardev",
+ .oval = FIO_TYPE_CHAR,
+ .help = "Character device",
+ },
+ {
+ .ival = "pipe",
+ .oval = FIO_TYPE_PIPE,
+ .help = "Pipe",
+ },
+ },
+ },
+ {
.name = "lockfile",
.lname = "Lockfile",
.type = FIO_OPT_STR,
diff --git a/thread_options.h b/thread_options.h
index a45d7b79b7ef..d90d3d7de683 100644
--- a/thread_options.h
+++ b/thread_options.h
@@ -40,6 +40,7 @@ struct thread_options {
char *opendir;
char *ioengine;
char *mmapfile;
+ unsigned int filetype;
enum td_ddir td_ddir;
unsigned int rw_seq;
unsigned int kb_base;
@@ -271,6 +272,7 @@ struct thread_options_pack {
uint8_t opendir[FIO_TOP_STR_MAX];
uint8_t ioengine[FIO_TOP_STR_MAX];
uint8_t mmapfile[FIO_TOP_STR_MAX];
+ uint32_t filetype;
uint32_t td_ddir;
uint32_t rw_seq;
uint32_t kb_base;
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-10-01 3:43 ` Jens Axboe
@ 2014-10-01 7:36 ` Sitsofe Wheeler
2014-10-01 14:20 ` Jens Axboe
2014-10-01 23:52 ` Elliott, Robert (Server Storage)
1 sibling, 1 reply; 19+ messages in thread
From: Sitsofe Wheeler @ 2014-10-01 7:36 UTC (permalink / raw)
To: Jens Axboe
Cc: Elliott, Robert (Server Storage), fio@vger.kernel.org, Jon Tango
On 1 October 2014 04:43, Jens Axboe <axboe@kernel.dk> wrote:
> On 2014-09-30 19:17, Jens Axboe wrote:
>>
>> On 2014-09-30 19:12, Elliott, Robert (Server Storage) wrote:
>>>
>>>> -----Original Message-----
>>>> From: Jens Axboe [mailto:axboe@kernel.dk]
>>>>
>>>> I'd much rather keep fio ignorant of any "special" directories, even if
>>>> it means that sometimes you do potentially run into issues like the
>>>> above, where you specify a block device that does not exist.
>>>
>>> How about an option in the script:
>>> direct=2 file must exist and be a block device, otherwise skip it
>>
>> Might be a bit nasty to overload direct= like that. But I'd be open to
>> adding an option that says must_be_bdev or something, which can be a
>> bool as well.
>
> So for your case, you'd set
>
> filetype=bdev
How about a create parameter which defaults to create=1 giving the
current behaviour and create=0 where the job fails if the file doesn't
already exist? It won't catch as much but should be portable.
--
Sitsofe | http://sucs.org/~sits/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-10-01 7:36 ` Sitsofe Wheeler
@ 2014-10-01 14:20 ` Jens Axboe
2014-10-01 14:31 ` Elliott, Robert (Server Storage)
0 siblings, 1 reply; 19+ messages in thread
From: Jens Axboe @ 2014-10-01 14:20 UTC (permalink / raw)
To: Sitsofe Wheeler
Cc: Elliott, Robert (Server Storage), fio@vger.kernel.org, Jon Tango
On 2014-10-01 01:36, Sitsofe Wheeler wrote:
> On 1 October 2014 04:43, Jens Axboe <axboe@kernel.dk> wrote:
>> On 2014-09-30 19:17, Jens Axboe wrote:
>>>
>>> On 2014-09-30 19:12, Elliott, Robert (Server Storage) wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Jens Axboe [mailto:axboe@kernel.dk]
>>>>>
>>>>> I'd much rather keep fio ignorant of any "special" directories, even if
>>>>> it means that sometimes you do potentially run into issues like the
>>>>> above, where you specify a block device that does not exist.
>>>>
>>>> How about an option in the script:
>>>> direct=2 file must exist and be a block device, otherwise skip it
>>>
>>> Might be a bit nasty to overload direct= like that. But I'd be open to
>>> adding an option that says must_be_bdev or something, which can be a
>>> bool as well.
>>
>> So for your case, you'd set
>>
>> filetype=bdev
>
> How about a create parameter which defaults to create=1 giving the
> current behaviour and create=0 where the job fails if the file doesn't
> already exist? It won't catch as much but should be portable.
Agree, that will be both easier to maintain and probably just as useful
as the more expanded options. Lets call it 'allow_file_create'.
--
Jens Axboe
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: linux /dev and normal files
2014-10-01 14:20 ` Jens Axboe
@ 2014-10-01 14:31 ` Elliott, Robert (Server Storage)
0 siblings, 0 replies; 19+ messages in thread
From: Elliott, Robert (Server Storage) @ 2014-10-01 14:31 UTC (permalink / raw)
To: Jens Axboe, Sitsofe Wheeler; +Cc: fio@vger.kernel.org, Jon Tango
...
> >>>>> I'd much rather keep fio ignorant of any "special" directories, even if
> >>>>> it means that sometimes you do potentially run into issues like the
> >>>>> above, where you specify a block device that does not exist.
> >>>>
> >>>> How about an option in the script:
> >>>> direct=2 file must exist and be a block device, otherwise skip it
> >>>
> >>> Might be a bit nasty to overload direct= like that. But I'd be open to
> >>> adding an option that says must_be_bdev or something, which can be a
> >>> bool as well.
> >>
> >> So for your case, you'd set
> >> filetype=bdev
> >
> > How about a create parameter which defaults to create=1 giving the
> > current behaviour and create=0 where the job fails if the file doesn't
> > already exist? It won't catch as much but should be portable.
>
> Agree, that will be both easier to maintain and probably just as useful
> as the more expanded options. Lets call it 'allow_file_create'.
>
Thanks, I'll create a patch to add that.
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: linux /dev and normal files
2014-10-01 3:43 ` Jens Axboe
2014-10-01 7:36 ` Sitsofe Wheeler
@ 2014-10-01 23:52 ` Elliott, Robert (Server Storage)
2014-10-02 0:58 ` Jens Axboe
1 sibling, 1 reply; 19+ messages in thread
From: Elliott, Robert (Server Storage) @ 2014-10-01 23:52 UTC (permalink / raw)
To: Jens Axboe, fio@vger.kernel.org; +Cc: Sitsofe Wheeler, Jon Tango
> -----Original Message-----
> From: Jens Axboe [mailto:axboe@kernel.dk]
> Sent: Tuesday, 30 September, 2014 10:43 PM
> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
> Cc: Sitsofe Wheeler; Jon Tango
> Subject: Re: linux /dev and normal files
>
> On 2014-09-30 19:17, Jens Axboe wrote:
> > On 2014-09-30 19:12, Elliott, Robert (Server Storage) wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jens Axboe [mailto:axboe@kernel.dk]
> >> ...
> >>> I'd much rather keep fio ignorant of any "special" directories, even if
> >>> it means that sometimes you do potentially run into issues like the
> >>> above, where you specify a block device that does not exist.
> >>
> >> How about an option in the script:
> >> direct=2 file must exist and be a block device, otherwise skip it
> >
> > Might be a bit nasty to overload direct= like that. But I'd be open to
> > adding an option that says must_be_bdev or something, which can be a
> > bool as well.
>
> Totally untested patch attached (it compiles). There's a new option,
> filetype. If not set, if will allow any file type. Can be set to:
>
> any default, allow any file type
> file regular file
> bdev block device
> chardev character device
> pipe pipe
>
> So for your case, you'd set
>
> filetype=bdev
>
> and you'd avoid the issue. Note that it only works for files specified
> with filename=. Any other way of adding a file (blktrace replay,
> opendir=, or fio added files when no filename= given) will ignore the
> filetype setting.
Tested with 16 devices sdr to sdag, where sdaf and sdag are
offline.
It prints a message about sdaf and exits, and does not
create a normal file in that location:
parse 11480 [drive_af]
parse 11480 Parsing section [drive_af]
file 11480 dup files: 0
parse 11480 filename=/dev/sdaf
parse 11480
parse 11480 [drive_ag]
parse 11480 handle_option=filename, ptr=/dev/sdaf
parse 11480 __handle_option=filename, type=5, ptr=/dev/sdaf
file 11480 add file /dev/sdaf
file 11480 resize file array to 1 files
fio: dropping file '/dev/sdaf' of wrong type
fio: wanted bdev, got file
fio: failed parsing filename=/dev/sdaf
fio: job drive_af dropped
parse 11480 free options
parse 11480 free options
io 11480 ioengine cpuio unregistered
io 11480 ioengine mmap unregistered
io 11480 ioengine sync unregistered
...
compared to a bdev that exists:
parse 11480 handle_option=filename, ptr=/dev/sdae
parse 11480 __handle_option=filename, type=5, ptr=/dev/sdae
file 11480 add file /dev/sdae
file 11480 resize file array to 1 files
file 11480 file 0x7f7903703a90 "/dev/sdae" added at 0
io 11480 load ioengine libaio
parse 11480 init options
drive_ae: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=96
file 11480 dup files: 1
io 11480 load ioengine libaio
That is because the do {} while (!ret) loop in
__parse_jobs_ini gives up on the first add_job failure.
add_job calls parse_options which calls handle_option
which fails.
It might be better to continue to attempt to run the
other jobs.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-10-01 23:52 ` Elliott, Robert (Server Storage)
@ 2014-10-02 0:58 ` Jens Axboe
2014-10-02 1:03 ` Jens Axboe
0 siblings, 1 reply; 19+ messages in thread
From: Jens Axboe @ 2014-10-02 0:58 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
On 2014-10-01 17:52, Elliott, Robert (Server Storage) wrote:
>
>
>> -----Original Message-----
>> From: Jens Axboe [mailto:axboe@kernel.dk]
>> Sent: Tuesday, 30 September, 2014 10:43 PM
>> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
>> Cc: Sitsofe Wheeler; Jon Tango
>> Subject: Re: linux /dev and normal files
>>
>> On 2014-09-30 19:17, Jens Axboe wrote:
>>> On 2014-09-30 19:12, Elliott, Robert (Server Storage) wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Jens Axboe [mailto:axboe@kernel.dk]
>>>> ...
>>>>> I'd much rather keep fio ignorant of any "special" directories, even if
>>>>> it means that sometimes you do potentially run into issues like the
>>>>> above, where you specify a block device that does not exist.
>>>>
>>>> How about an option in the script:
>>>> direct=2 file must exist and be a block device, otherwise skip it
>>>
>>> Might be a bit nasty to overload direct= like that. But I'd be open to
>>> adding an option that says must_be_bdev or something, which can be a
>>> bool as well.
>>
>> Totally untested patch attached (it compiles). There's a new option,
>> filetype. If not set, if will allow any file type. Can be set to:
>>
>> any default, allow any file type
>> file regular file
>> bdev block device
>> chardev character device
>> pipe pipe
>>
>> So for your case, you'd set
>>
>> filetype=bdev
>>
>> and you'd avoid the issue. Note that it only works for files specified
>> with filename=. Any other way of adding a file (blktrace replay,
>> opendir=, or fio added files when no filename= given) will ignore the
>> filetype setting.
>
> Tested with 16 devices sdr to sdag, where sdaf and sdag are
> offline.
>
> It prints a message about sdaf and exits, and does not
> create a normal file in that location:
> parse 11480 [drive_af]
> parse 11480 Parsing section [drive_af]
> file 11480 dup files: 0
> parse 11480 filename=/dev/sdaf
> parse 11480
> parse 11480 [drive_ag]
> parse 11480 handle_option=filename, ptr=/dev/sdaf
> parse 11480 __handle_option=filename, type=5, ptr=/dev/sdaf
> file 11480 add file /dev/sdaf
> file 11480 resize file array to 1 files
> fio: dropping file '/dev/sdaf' of wrong type
> fio: wanted bdev, got file
> fio: failed parsing filename=/dev/sdaf
> fio: job drive_af dropped
> parse 11480 free options
> parse 11480 free options
> io 11480 ioengine cpuio unregistered
> io 11480 ioengine mmap unregistered
> io 11480 ioengine sync unregistered
> ...
>
> compared to a bdev that exists:
> parse 11480 handle_option=filename, ptr=/dev/sdae
> parse 11480 __handle_option=filename, type=5, ptr=/dev/sdae
> file 11480 add file /dev/sdae
> file 11480 resize file array to 1 files
> file 11480 file 0x7f7903703a90 "/dev/sdae" added at 0
> io 11480 load ioengine libaio
> parse 11480 init options
> drive_ae: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=96
> file 11480 dup files: 1
> io 11480 load ioengine libaio
>
> That is because the do {} while (!ret) loop in
> __parse_jobs_ini gives up on the first add_job failure.
> add_job calls parse_options which calls handle_option
> which fails.
>
> It might be better to continue to attempt to run the
> other jobs.
We should just go for the simpler create/nocreate solution, I prefer
that. This is too involved, and it's hard to get all the cases right
since there are a bunch of different ways that files are added. Which
was why this patch only focused on filename=, since that is the one that
is the most interesting. But it still isn't pretty. If we add the
allow_file_create option, it's basically a two-liner change in a few
places to not use O_CREAT.
--
Jens Axboe
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-10-02 0:58 ` Jens Axboe
@ 2014-10-02 1:03 ` Jens Axboe
2014-10-02 18:21 ` Elliott, Robert (Server Storage)
0 siblings, 1 reply; 19+ messages in thread
From: Jens Axboe @ 2014-10-02 1:03 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
[-- Attachment #1: Type: text/plain, Size: 4022 bytes --]
On 2014-10-01 18:58, Jens Axboe wrote:
> On 2014-10-01 17:52, Elliott, Robert (Server Storage) wrote:
>>
>>
>>> -----Original Message-----
>>> From: Jens Axboe [mailto:axboe@kernel.dk]
>>> Sent: Tuesday, 30 September, 2014 10:43 PM
>>> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
>>> Cc: Sitsofe Wheeler; Jon Tango
>>> Subject: Re: linux /dev and normal files
>>>
>>> On 2014-09-30 19:17, Jens Axboe wrote:
>>>> On 2014-09-30 19:12, Elliott, Robert (Server Storage) wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jens Axboe [mailto:axboe@kernel.dk]
>>>>> ...
>>>>>> I'd much rather keep fio ignorant of any "special" directories,
>>>>>> even if
>>>>>> it means that sometimes you do potentially run into issues like the
>>>>>> above, where you specify a block device that does not exist.
>>>>>
>>>>> How about an option in the script:
>>>>> direct=2 file must exist and be a block device, otherwise skip it
>>>>
>>>> Might be a bit nasty to overload direct= like that. But I'd be open to
>>>> adding an option that says must_be_bdev or something, which can be a
>>>> bool as well.
>>>
>>> Totally untested patch attached (it compiles). There's a new option,
>>> filetype. If not set, if will allow any file type. Can be set to:
>>>
>>> any default, allow any file type
>>> file regular file
>>> bdev block device
>>> chardev character device
>>> pipe pipe
>>>
>>> So for your case, you'd set
>>>
>>> filetype=bdev
>>>
>>> and you'd avoid the issue. Note that it only works for files specified
>>> with filename=. Any other way of adding a file (blktrace replay,
>>> opendir=, or fio added files when no filename= given) will ignore the
>>> filetype setting.
>>
>> Tested with 16 devices sdr to sdag, where sdaf and sdag are
>> offline.
>>
>> It prints a message about sdaf and exits, and does not
>> create a normal file in that location:
>> parse 11480 [drive_af]
>> parse 11480 Parsing section [drive_af]
>> file 11480 dup files: 0
>> parse 11480 filename=/dev/sdaf
>> parse 11480
>> parse 11480 [drive_ag]
>> parse 11480 handle_option=filename, ptr=/dev/sdaf
>> parse 11480 __handle_option=filename, type=5, ptr=/dev/sdaf
>> file 11480 add file /dev/sdaf
>> file 11480 resize file array to 1 files
>> fio: dropping file '/dev/sdaf' of wrong type
>> fio: wanted bdev, got file
>> fio: failed parsing filename=/dev/sdaf
>> fio: job drive_af dropped
>> parse 11480 free options
>> parse 11480 free options
>> io 11480 ioengine cpuio unregistered
>> io 11480 ioengine mmap unregistered
>> io 11480 ioengine sync unregistered
>> ...
>>
>> compared to a bdev that exists:
>> parse 11480 handle_option=filename, ptr=/dev/sdae
>> parse 11480 __handle_option=filename, type=5, ptr=/dev/sdae
>> file 11480 add file /dev/sdae
>> file 11480 resize file array to 1 files
>> file 11480 file 0x7f7903703a90 "/dev/sdae" added at 0
>> io 11480 load ioengine libaio
>> parse 11480 init options
>> drive_ae: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio,
>> iodepth=96
>> file 11480 dup files: 1
>> io 11480 load ioengine libaio
>>
>> That is because the do {} while (!ret) loop in
>> __parse_jobs_ini gives up on the first add_job failure.
>> add_job calls parse_options which calls handle_option
>> which fails.
>>
>> It might be better to continue to attempt to run the
>> other jobs.
>
> We should just go for the simpler create/nocreate solution, I prefer
> that. This is too involved, and it's hard to get all the cases right
> since there are a bunch of different ways that files are added. Which
> was why this patch only focused on filename=, since that is the one that
> is the most interesting. But it still isn't pretty. If we add the
> allow_file_create option, it's basically a two-liner change in a few
> places to not use O_CREAT.
That took roughly 4 minutes... Does this work? Set allow_file_create=0
to disallow creating new files.
--
Jens Axboe
[-- Attachment #2: allow-create.patch --]
[-- Type: text/x-patch, Size: 2747 bytes --]
diff --git a/cconv.c b/cconv.c
index 4a40ed0d647b..913313b68d47 100644
--- a/cconv.c
+++ b/cconv.c
@@ -69,6 +69,7 @@ void convert_thread_options_to_cpu(struct thread_options *o,
string_to_cpu(&o->profile, top->profile);
string_to_cpu(&o->cgroup, top->cgroup);
+ o->allow_create = le32_to_cpu(top->allow_create);
o->td_ddir = le32_to_cpu(top->td_ddir);
o->rw_seq = le32_to_cpu(top->rw_seq);
o->kb_base = le32_to_cpu(top->kb_base);
@@ -278,6 +279,7 @@ void convert_thread_options_to_net(struct thread_options_pack *top,
string_to_net(top->profile, o->profile);
string_to_net(top->cgroup, o->cgroup);
+ top->allow_create = cpu_to_le32(o->allow_create);
top->td_ddir = cpu_to_le32(o->td_ddir);
top->rw_seq = cpu_to_le32(o->rw_seq);
top->kb_base = cpu_to_le32(o->kb_base);
diff --git a/filesetup.c b/filesetup.c
index 43146ba7671f..5b0c82208199 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -65,7 +65,9 @@ static int extend_file(struct thread_data *td, struct fio_file *f)
}
}
- flags = O_WRONLY | O_CREAT;
+ flags = O_WRONLY;
+ if (td->o.allow_create)
+ flags |= O_CREAT;
if (new_layout)
flags |= O_TRUNC;
@@ -557,7 +559,7 @@ int generic_open_file(struct thread_data *td, struct fio_file *f)
}
if (td->o.sync_io)
flags |= O_SYNC;
- if (td->o.create_on_open)
+ if (td->o.create_on_open && td->o.allow_create)
flags |= O_CREAT;
skip_flags:
if (f->filetype != FIO_TYPE_FILE)
@@ -568,7 +570,7 @@ open_again:
if (!read_only)
flags |= O_RDWR;
- if (f->filetype == FIO_TYPE_FILE)
+ if (f->filetype == FIO_TYPE_FILE && td->o.allow_create)
flags |= O_CREAT;
if (is_std)
diff --git a/options.c b/options.c
index 918de8e8e34b..b6bf47264880 100644
--- a/options.c
+++ b/options.c
@@ -1359,6 +1359,15 @@ struct fio_option fio_options[FIO_MAX_OPTS] = {
.group = FIO_OPT_G_FILENAME,
},
{
+ .name = "allow_file_create",
+ .type = FIO_OPT_BOOL,
+ .off1 = td_var_offset(allow_create),
+ .help = "Permit fio to create files, if they don't exist",
+ .def = "1",
+ .category = FIO_OPT_C_FILE,
+ .group = FIO_OPT_G_FILENAME,
+ },
+ {
.name = "lockfile",
.lname = "Lockfile",
.type = FIO_OPT_STR,
diff --git a/thread_options.h b/thread_options.h
index a45d7b79b7ef..dd576643b31c 100644
--- a/thread_options.h
+++ b/thread_options.h
@@ -41,6 +41,7 @@ struct thread_options {
char *ioengine;
char *mmapfile;
enum td_ddir td_ddir;
+ unsigned int allow_create;
unsigned int rw_seq;
unsigned int kb_base;
unsigned int unit_base;
@@ -271,6 +272,7 @@ struct thread_options_pack {
uint8_t opendir[FIO_TOP_STR_MAX];
uint8_t ioengine[FIO_TOP_STR_MAX];
uint8_t mmapfile[FIO_TOP_STR_MAX];
+ uint32_t allow_create;
uint32_t td_ddir;
uint32_t rw_seq;
uint32_t kb_base;
^ permalink raw reply related [flat|nested] 19+ messages in thread
* RE: linux /dev and normal files
2014-10-02 1:03 ` Jens Axboe
@ 2014-10-02 18:21 ` Elliott, Robert (Server Storage)
2014-10-02 18:32 ` Jens Axboe
0 siblings, 1 reply; 19+ messages in thread
From: Elliott, Robert (Server Storage) @ 2014-10-02 18:21 UTC (permalink / raw)
To: Jens Axboe, fio@vger.kernel.org; +Cc: Sitsofe Wheeler, Jon Tango
> >> It might be better to continue to attempt to run the
> >> other jobs.
> >
> > We should just go for the simpler create/nocreate solution, I prefer
> > that. This is too involved, and it's hard to get all the cases right
> > since there are a bunch of different ways that files are added. Which
> > was why this patch only focused on filename=, since that is the one that
> > is the most interesting. But it still isn't pretty. If we add the
> > allow_file_create option, it's basically a two-liner change in a few
> > places to not use O_CREAT.
>
> That took roughly 4 minutes... Does this work? Set allow_file_create=0
> to disallow creating new files.
>
Mostly.
With no size= setting or size=xx%, the error messages it prints are
about the lack of size, not the fact that file creation is disallowed.
It does proceed to run the jobs that have valid filenames.
drive_af: you need to specify size=
fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
drive_af: you need to specify size=
fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
...
drive_ag: you need to specify size=
fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
Jobs: 168 (f=168): [r(168),X(24)] [0.0% done] [2449MB/0KB/0KB /s] [627K/0/0 iops] [eta 02d:11h:58m:33s]
With size=xxm (a fixed size), it prints complaints about O_DIRECT.
It does proceed to run the jobs that have valid filenames.
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT
fio: pid=21834, err=22/file:filesetup.c:613, func=open(/dev/sdaf), error=Invalid argument
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT
fio: pid=21846, err=22/file:filesetup.c:613, func=open(/dev/sdag), error=Invalid argument
fio: looks like your file system does not support direct=1/buffered=0
fio: destination does not support O_DIRECT
...
fio: pid=21856, err=22/file:filesetup.c:613, func=open(/dev/sdag), error=Invalid argument
Jobs: 168 (f=168): [r(168),X(24)] [0.0% done] [2449MB/0KB/0KB /s] [627K/0/0 iops] [eta 02d:11h:58m:50s]
---
Rob Elliott HP Server Storage
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-10-02 18:21 ` Elliott, Robert (Server Storage)
@ 2014-10-02 18:32 ` Jens Axboe
2014-10-02 18:41 ` Jens Axboe
2015-04-03 18:13 ` Elliott, Robert (Server Storage)
0 siblings, 2 replies; 19+ messages in thread
From: Jens Axboe @ 2014-10-02 18:32 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
On 10/02/2014 12:21 PM, Elliott, Robert (Server Storage) wrote:
>>>> It might be better to continue to attempt to run the
>>>> other jobs.
>>>
>>> We should just go for the simpler create/nocreate solution, I prefer
>>> that. This is too involved, and it's hard to get all the cases right
>>> since there are a bunch of different ways that files are added. Which
>>> was why this patch only focused on filename=, since that is the one that
>>> is the most interesting. But it still isn't pretty. If we add the
>>> allow_file_create option, it's basically a two-liner change in a few
>>> places to not use O_CREAT.
>>
>> That took roughly 4 minutes... Does this work? Set allow_file_create=0
>> to disallow creating new files.
>>
>
> Mostly.
>
> With no size= setting or size=xx%, the error messages it prints are
> about the lack of size, not the fact that file creation is disallowed.
> It does proceed to run the jobs that have valid filenames.
>
> drive_af: you need to specify size=
> fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
> drive_af: you need to specify size=
> fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
> ...
> drive_ag: you need to specify size=
> fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
> Jobs: 168 (f=168): [r(168),X(24)] [0.0% done] [2449MB/0KB/0KB /s] [627K/0/0 iops] [eta 02d:11h:58m:33s]
Fio always does this, if the file does not exist and no size is given.
The reason is that it doesn't know what size to create. But we can
augment that a little bit if allow_file_create == 0, since the size
setting would not change that.
> With size=xxm (a fixed size), it prints complaints about O_DIRECT.
> It does proceed to run the jobs that have valid filenames.
>
> fio: looks like your file system does not support direct=1/buffered=0
> fio: destination does not support O_DIRECT
> fio: pid=21834, err=22/file:filesetup.c:613, func=open(/dev/sdaf), error=Invalid argument
> fio: looks like your file system does not support direct=1/buffered=0
> fio: destination does not support O_DIRECT
> fio: pid=21846, err=22/file:filesetup.c:613, func=open(/dev/sdag), error=Invalid argument
> fio: looks like your file system does not support direct=1/buffered=0
> fio: destination does not support O_DIRECT
> ...
> fio: pid=21856, err=22/file:filesetup.c:613, func=open(/dev/sdag), error=Invalid argument
> Jobs: 168 (f=168): [r(168),X(24)] [0.0% done] [2449MB/0KB/0KB /s] [627K/0/0 iops] [eta 02d:11h:58m:50s]
OK, let me test that, will spin a new one.
--
Jens Axboe
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2014-10-02 18:32 ` Jens Axboe
@ 2014-10-02 18:41 ` Jens Axboe
2015-04-03 18:13 ` Elliott, Robert (Server Storage)
1 sibling, 0 replies; 19+ messages in thread
From: Jens Axboe @ 2014-10-02 18:41 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]
On 10/02/2014 12:32 PM, Jens Axboe wrote:
> On 10/02/2014 12:21 PM, Elliott, Robert (Server Storage) wrote:
>>>>> It might be better to continue to attempt to run the
>>>>> other jobs.
>>>>
>>>> We should just go for the simpler create/nocreate solution, I prefer
>>>> that. This is too involved, and it's hard to get all the cases right
>>>> since there are a bunch of different ways that files are added. Which
>>>> was why this patch only focused on filename=, since that is the one that
>>>> is the most interesting. But it still isn't pretty. If we add the
>>>> allow_file_create option, it's basically a two-liner change in a few
>>>> places to not use O_CREAT.
>>>
>>> That took roughly 4 minutes... Does this work? Set allow_file_create=0
>>> to disallow creating new files.
>>>
>>
>> Mostly.
>>
>> With no size= setting or size=xx%, the error messages it prints are
>> about the lack of size, not the fact that file creation is disallowed.
>> It does proceed to run the jobs that have valid filenames.
>>
>> drive_af: you need to specify size=
>> fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
>> drive_af: you need to specify size=
>> fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
>> ...
>> drive_ag: you need to specify size=
>> fio: pid=0, err=22/file:filesetup.c:822, func=total_file_size, error=Invalid argument
>> Jobs: 168 (f=168): [r(168),X(24)] [0.0% done] [2449MB/0KB/0KB /s] [627K/0/0 iops] [eta 02d:11h:58m:33s]
>
> Fio always does this, if the file does not exist and no size is given.
> The reason is that it doesn't know what size to create. But we can
> augment that a little bit if allow_file_create == 0, since the size
> setting would not change that.
>
>> With size=xxm (a fixed size), it prints complaints about O_DIRECT.
>> It does proceed to run the jobs that have valid filenames.
>>
>> fio: looks like your file system does not support direct=1/buffered=0
>> fio: destination does not support O_DIRECT
>> fio: pid=21834, err=22/file:filesetup.c:613, func=open(/dev/sdaf), error=Invalid argument
>> fio: looks like your file system does not support direct=1/buffered=0
>> fio: destination does not support O_DIRECT
>> fio: pid=21846, err=22/file:filesetup.c:613, func=open(/dev/sdag), error=Invalid argument
>> fio: looks like your file system does not support direct=1/buffered=0
>> fio: destination does not support O_DIRECT
>> ...
>> fio: pid=21856, err=22/file:filesetup.c:613, func=open(/dev/sdag), error=Invalid argument
>> Jobs: 168 (f=168): [r(168),X(24)] [0.0% done] [2449MB/0KB/0KB /s] [627K/0/0 iops] [eta 02d:11h:58m:50s]
>
> OK, let me test that, will spin a new one.
This works for me - though I cannot reproduce your O_DIRECT warning
above, what was run to generate that?
--
Jens Axboe
[-- Attachment #2: create-v2.patch --]
[-- Type: text/x-patch, Size: 4863 bytes --]
diff --git a/HOWTO b/HOWTO
index 693eeb11b12a..854843df5ea9 100644
--- a/HOWTO
+++ b/HOWTO
@@ -1160,6 +1160,11 @@ create_only=bool If true, fio will only run the setup phase of the job.
that will be done. The actual job contents are not
executed.
+allow_file_create=bool If true, fio is permitted to create files as part
+ of its workload. This is the default behavior. If this
+ option is false, then fio will error out if the files it
+ needs to use don't already exist.
+
pre_read=bool If this is given, files will be pre-read into memory before
starting the given IO operation. This will also clear
the 'invalidate' flag, since it is pointless to pre-read
diff --git a/cconv.c b/cconv.c
index 4a40ed0d647b..913313b68d47 100644
--- a/cconv.c
+++ b/cconv.c
@@ -69,6 +69,7 @@ void convert_thread_options_to_cpu(struct thread_options *o,
string_to_cpu(&o->profile, top->profile);
string_to_cpu(&o->cgroup, top->cgroup);
+ o->allow_create = le32_to_cpu(top->allow_create);
o->td_ddir = le32_to_cpu(top->td_ddir);
o->rw_seq = le32_to_cpu(top->rw_seq);
o->kb_base = le32_to_cpu(top->kb_base);
@@ -278,6 +279,7 @@ void convert_thread_options_to_net(struct thread_options_pack *top,
string_to_net(top->profile, o->profile);
string_to_net(top->cgroup, o->cgroup);
+ top->allow_create = cpu_to_le32(o->allow_create);
top->td_ddir = cpu_to_le32(o->td_ddir);
top->rw_seq = cpu_to_le32(o->rw_seq);
top->kb_base = cpu_to_le32(o->kb_base);
diff --git a/filesetup.c b/filesetup.c
index 43146ba7671f..cca877634e95 100644
--- a/filesetup.c
+++ b/filesetup.c
@@ -65,7 +65,9 @@ static int extend_file(struct thread_data *td, struct fio_file *f)
}
}
- flags = O_WRONLY | O_CREAT;
+ flags = O_WRONLY;
+ if (td->o.allow_create)
+ flags |= O_CREAT;
if (new_layout)
flags |= O_TRUNC;
@@ -76,7 +78,13 @@ static int extend_file(struct thread_data *td, struct fio_file *f)
dprint(FD_FILE, "open file %s, flags %x\n", f->file_name, flags);
f->fd = open(f->file_name, flags, 0644);
if (f->fd < 0) {
- td_verror(td, errno, "open");
+ int err = errno;
+
+ if (err == ENOENT && !td->o.allow_create)
+ log_err("fio: file creation disallowed by "
+ "allow_file_create=0\n");
+ else
+ td_verror(td, err, "open");
return 1;
}
@@ -557,7 +565,7 @@ int generic_open_file(struct thread_data *td, struct fio_file *f)
}
if (td->o.sync_io)
flags |= O_SYNC;
- if (td->o.create_on_open)
+ if (td->o.create_on_open && td->o.allow_create)
flags |= O_CREAT;
skip_flags:
if (f->filetype != FIO_TYPE_FILE)
@@ -568,7 +576,7 @@ open_again:
if (!read_only)
flags |= O_RDWR;
- if (f->filetype == FIO_TYPE_FILE)
+ if (f->filetype == FIO_TYPE_FILE && td->o.allow_create)
flags |= O_CREAT;
if (is_std)
diff --git a/fio.1 b/fio.1
index d64fbb7ab5e0..ef53bd6302a7 100644
--- a/fio.1
+++ b/fio.1
@@ -1029,6 +1029,11 @@ If true, fio will only run the setup phase of the job. If files need to be
laid out or updated on disk, only that will be done. The actual job contents
are not executed.
.TP
+.BI allow_file_create \fR=\fPbool
+If true, fio is permitted to create files as part of its workload. This is
+the default behavior. If this option is false, then fio will error out if the
+files it needs to use don't already exist.
+.TP
.BI pre_read \fR=\fPbool
If this is given, files will be pre-read into memory before starting the given
IO operation. This will also clear the \fR \fBinvalidate\fR flag, since it is
diff --git a/options.c b/options.c
index 918de8e8e34b..a7dd58adb418 100644
--- a/options.c
+++ b/options.c
@@ -2962,6 +2962,15 @@ struct fio_option fio_options[FIO_MAX_OPTS] = {
.def = "0",
},
{
+ .name = "allow_file_create",
+ .type = FIO_OPT_BOOL,
+ .off1 = td_var_offset(allow_create),
+ .help = "Permit fio to create files, if they don't exist",
+ .def = "1",
+ .category = FIO_OPT_C_FILE,
+ .group = FIO_OPT_G_FILENAME,
+ },
+ {
.name = "pre_read",
.lname = "Pre-read files",
.type = FIO_OPT_BOOL,
diff --git a/server.h b/server.h
index 1b131b92f08a..5213e6ac9e08 100644
--- a/server.h
+++ b/server.h
@@ -38,7 +38,7 @@ struct fio_net_cmd_reply {
};
enum {
- FIO_SERVER_VER = 36,
+ FIO_SERVER_VER = 37,
FIO_SERVER_MAX_FRAGMENT_PDU = 1024,
FIO_SERVER_MAX_CMD_MB = 2048,
diff --git a/thread_options.h b/thread_options.h
index a45d7b79b7ef..5cf697d2bb9c 100644
--- a/thread_options.h
+++ b/thread_options.h
@@ -40,6 +40,7 @@ struct thread_options {
char *opendir;
char *ioengine;
char *mmapfile;
+ unsigned int allow_create;
enum td_ddir td_ddir;
unsigned int rw_seq;
unsigned int kb_base;
@@ -271,6 +272,7 @@ struct thread_options_pack {
uint8_t opendir[FIO_TOP_STR_MAX];
uint8_t ioengine[FIO_TOP_STR_MAX];
uint8_t mmapfile[FIO_TOP_STR_MAX];
+ uint32_t allow_create;
uint32_t td_ddir;
uint32_t rw_seq;
uint32_t kb_base;
^ permalink raw reply related [flat|nested] 19+ messages in thread
* RE: linux /dev and normal files
2014-10-02 18:32 ` Jens Axboe
2014-10-02 18:41 ` Jens Axboe
@ 2015-04-03 18:13 ` Elliott, Robert (Server Storage)
2015-04-03 18:24 ` Jens Axboe
1 sibling, 1 reply; 19+ messages in thread
From: Elliott, Robert (Server Storage) @ 2015-04-03 18:13 UTC (permalink / raw)
To: Jens Axboe, fio@vger.kernel.org; +Cc: Sitsofe Wheeler, Jon Tango
> -----Original Message-----
> From: fio-owner@vger.kernel.org [mailto:fio-owner@vger.kernel.org] On
> Behalf Of Jens Axboe
> Sent: Thursday, October 2, 2014 1:32 PM
> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
> Cc: Sitsofe Wheeler; Jon Tango
> Subject: Re: linux /dev and normal files
>
> On 10/02/2014 12:21 PM, Elliott, Robert (Server Storage) wrote:
> >>>> It might be better to continue to attempt to run the
> >>>> other jobs.
> >>>
> >>> We should just go for the simpler create/nocreate solution, I prefer
> >>> that. This is too involved, and it's hard to get all the cases right
> >>> since there are a bunch of different ways that files are added. Which
> >>> was why this patch only focused on filename=, since that is the one
> that
> >>> is the most interesting. But it still isn't pretty. If we add the
> >>> allow_file_create option, it's basically a two-liner change in a few
> >>> places to not use O_CREAT.
> >>
> >> That took roughly 4 minutes... Does this work? Set allow_file_create=0
> >> to disallow creating new files.
...
>
> OK, let me test that, will spin a new one.
I don't think this ever got added.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2015-04-03 18:13 ` Elliott, Robert (Server Storage)
@ 2015-04-03 18:24 ` Jens Axboe
2015-05-12 15:32 ` Jens Axboe
0 siblings, 1 reply; 19+ messages in thread
From: Jens Axboe @ 2015-04-03 18:24 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
On 04/03/2015 12:13 PM, Elliott, Robert (Server Storage) wrote:
>
>
>> -----Original Message-----
>> From: fio-owner@vger.kernel.org [mailto:fio-owner@vger.kernel.org] On
>> Behalf Of Jens Axboe
>> Sent: Thursday, October 2, 2014 1:32 PM
>> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
>> Cc: Sitsofe Wheeler; Jon Tango
>> Subject: Re: linux /dev and normal files
>>
>> On 10/02/2014 12:21 PM, Elliott, Robert (Server Storage) wrote:
>>>>>> It might be better to continue to attempt to run the
>>>>>> other jobs.
>>>>>
>>>>> We should just go for the simpler create/nocreate solution, I prefer
>>>>> that. This is too involved, and it's hard to get all the cases right
>>>>> since there are a bunch of different ways that files are added. Which
>>>>> was why this patch only focused on filename=, since that is the one
>> that
>>>>> is the most interesting. But it still isn't pretty. If we add the
>>>>> allow_file_create option, it's basically a two-liner change in a few
>>>>> places to not use O_CREAT.
>>>>
>>>> That took roughly 4 minutes... Does this work? Set allow_file_create=0
>>>> to disallow creating new files.
> ...
>>
>> OK, let me test that, will spin a new one.
>
> I don't think this ever got added.
It didn't... Did you re-test? No reason we can't get it added, I'll look
into it start next week.
--
Jens Axboe
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2015-04-03 18:24 ` Jens Axboe
@ 2015-05-12 15:32 ` Jens Axboe
2015-05-12 16:34 ` Elliott, Robert (Server Storage)
0 siblings, 1 reply; 19+ messages in thread
From: Jens Axboe @ 2015-05-12 15:32 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
On 04/03/2015 02:24 PM, Jens Axboe wrote:
> On 04/03/2015 12:13 PM, Elliott, Robert (Server Storage) wrote:
>>
>>
>>> -----Original Message-----
>>> From: fio-owner@vger.kernel.org [mailto:fio-owner@vger.kernel.org] On
>>> Behalf Of Jens Axboe
>>> Sent: Thursday, October 2, 2014 1:32 PM
>>> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
>>> Cc: Sitsofe Wheeler; Jon Tango
>>> Subject: Re: linux /dev and normal files
>>>
>>> On 10/02/2014 12:21 PM, Elliott, Robert (Server Storage) wrote:
>>>>>>> It might be better to continue to attempt to run the
>>>>>>> other jobs.
>>>>>>
>>>>>> We should just go for the simpler create/nocreate solution, I prefer
>>>>>> that. This is too involved, and it's hard to get all the cases right
>>>>>> since there are a bunch of different ways that files are added. Which
>>>>>> was why this patch only focused on filename=, since that is the one
>>> that
>>>>>> is the most interesting. But it still isn't pretty. If we add the
>>>>>> allow_file_create option, it's basically a two-liner change in a few
>>>>>> places to not use O_CREAT.
>>>>>
>>>>> That took roughly 4 minutes... Does this work? Set allow_file_create=0
>>>>> to disallow creating new files.
>> ...
>>>
>>> OK, let me test that, will spin a new one.
>>
>> I don't think this ever got added.
>
> It didn't... Did you re-test? No reason we can't get it added, I'll look
> into it start next week.
Robert, I added this. Can you check current -git and see if it behaves
as expected for you?
--
Jens Axboe
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: linux /dev and normal files
2015-05-12 15:32 ` Jens Axboe
@ 2015-05-12 16:34 ` Elliott, Robert (Server Storage)
2015-05-12 17:56 ` Jens Axboe
0 siblings, 1 reply; 19+ messages in thread
From: Elliott, Robert (Server Storage) @ 2015-05-12 16:34 UTC (permalink / raw)
To: Jens Axboe, fio@vger.kernel.org; +Cc: Sitsofe Wheeler, Jon Tango
> -----Original Message-----
> From: Jens Axboe [mailto:axboe@kernel.dk]
> Sent: Tuesday, May 12, 2015 10:33 AM
> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
> Cc: Sitsofe Wheeler; Jon Tango
> Subject: Re: linux /dev and normal files
>
> On 04/03/2015 02:24 PM, Jens Axboe wrote:
> > On 04/03/2015 12:13 PM, Elliott, Robert (Server Storage) wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: fio-owner@vger.kernel.org [mailto:fio-owner@vger.kernel.org] On
> >>> Behalf Of Jens Axboe
> >>> Sent: Thursday, October 2, 2014 1:32 PM
> >>> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
> >>> Cc: Sitsofe Wheeler; Jon Tango
> >>> Subject: Re: linux /dev and normal files
> >>>
> >>> On 10/02/2014 12:21 PM, Elliott, Robert (Server Storage) wrote:
> >>>>>>> It might be better to continue to attempt to run the
> >>>>>>> other jobs.
> >>>>>>
> >>>>>> We should just go for the simpler create/nocreate solution, I
> prefer
> >>>>>> that. This is too involved, and it's hard to get all the cases
> right
> >>>>>> since there are a bunch of different ways that files are added.
> Which
> >>>>>> was why this patch only focused on filename=, since that is the one
> >>> that
> >>>>>> is the most interesting. But it still isn't pretty. If we add the
> >>>>>> allow_file_create option, it's basically a two-liner change in a
> few
> >>>>>> places to not use O_CREAT.
> >>>>>
> >>>>> That took roughly 4 minutes... Does this work? Set
> allow_file_create=0
> >>>>> to disallow creating new files.
> >> ...
> >>>
> >>> OK, let me test that, will spin a new one.
> >>
> >> I don't think this ever got added.
> >
> > It didn't... Did you re-test? No reason we can't get it added, I'll look
> > into it start next week.
>
> Robert, I added this. Can you check current -git and see if it behaves
> as expected for you?
>
Looks good. Adding
allow_file_create=0
prevents it from creating files in /dev when the specified path
does not exist and size= is specified.
Starting 80 threads
drive_0: Laying out IO file(s) (1 file(s) / 10MB)
fio: file creation disallowed by allow_file_create=0
drive_0: Laying out IO file(s) (1 file(s) / 10MB)
fio: file creation disallowed by allow_file_create=0
drive_0: Laying out IO file(s) (1 file(s) / 10MB)
fio: file creation disallowed by allow_file_create=0
...
---
Robert Elliott, HP Server Storage
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux /dev and normal files
2015-05-12 16:34 ` Elliott, Robert (Server Storage)
@ 2015-05-12 17:56 ` Jens Axboe
0 siblings, 0 replies; 19+ messages in thread
From: Jens Axboe @ 2015-05-12 17:56 UTC (permalink / raw)
To: Elliott, Robert (Server Storage), fio@vger.kernel.org
Cc: Sitsofe Wheeler, Jon Tango
On 05/12/2015 12:34 PM, Elliott, Robert (Server Storage) wrote:
>
>> -----Original Message-----
>> From: Jens Axboe [mailto:axboe@kernel.dk]
>> Sent: Tuesday, May 12, 2015 10:33 AM
>> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
>> Cc: Sitsofe Wheeler; Jon Tango
>> Subject: Re: linux /dev and normal files
>>
>> On 04/03/2015 02:24 PM, Jens Axboe wrote:
>>> On 04/03/2015 12:13 PM, Elliott, Robert (Server Storage) wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: fio-owner@vger.kernel.org [mailto:fio-owner@vger.kernel.org] On
>>>>> Behalf Of Jens Axboe
>>>>> Sent: Thursday, October 2, 2014 1:32 PM
>>>>> To: Elliott, Robert (Server Storage); fio@vger.kernel.org
>>>>> Cc: Sitsofe Wheeler; Jon Tango
>>>>> Subject: Re: linux /dev and normal files
>>>>>
>>>>> On 10/02/2014 12:21 PM, Elliott, Robert (Server Storage) wrote:
>>>>>>>>> It might be better to continue to attempt to run the
>>>>>>>>> other jobs.
>>>>>>>>
>>>>>>>> We should just go for the simpler create/nocreate solution, I
>> prefer
>>>>>>>> that. This is too involved, and it's hard to get all the cases
>> right
>>>>>>>> since there are a bunch of different ways that files are added.
>> Which
>>>>>>>> was why this patch only focused on filename=, since that is the one
>>>>> that
>>>>>>>> is the most interesting. But it still isn't pretty. If we add the
>>>>>>>> allow_file_create option, it's basically a two-liner change in a
>> few
>>>>>>>> places to not use O_CREAT.
>>>>>>>
>>>>>>> That took roughly 4 minutes... Does this work? Set
>> allow_file_create=0
>>>>>>> to disallow creating new files.
>>>> ...
>>>>>
>>>>> OK, let me test that, will spin a new one.
>>>>
>>>> I don't think this ever got added.
>>>
>>> It didn't... Did you re-test? No reason we can't get it added, I'll look
>>> into it start next week.
>>
>> Robert, I added this. Can you check current -git and see if it behaves
>> as expected for you?
>>
>
> Looks good. Adding
> allow_file_create=0
>
> prevents it from creating files in /dev when the specified path
> does not exist and size= is specified.
>
> Starting 80 threads
> drive_0: Laying out IO file(s) (1 file(s) / 10MB)
> fio: file creation disallowed by allow_file_create=0
> drive_0: Laying out IO file(s) (1 file(s) / 10MB)
> fio: file creation disallowed by allow_file_create=0
> drive_0: Laying out IO file(s) (1 file(s) / 10MB)
> fio: file creation disallowed by allow_file_create=0
Perfect, thanks for (re) testing.
--
Jens Axboe
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2015-05-12 17:56 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-09-30 23:49 linux /dev and normal files Elliott, Robert (Server Storage)
2014-10-01 1:02 ` Jens Axboe
2014-10-01 1:12 ` Elliott, Robert (Server Storage)
2014-10-01 1:17 ` Jens Axboe
2014-10-01 3:43 ` Jens Axboe
2014-10-01 7:36 ` Sitsofe Wheeler
2014-10-01 14:20 ` Jens Axboe
2014-10-01 14:31 ` Elliott, Robert (Server Storage)
2014-10-01 23:52 ` Elliott, Robert (Server Storage)
2014-10-02 0:58 ` Jens Axboe
2014-10-02 1:03 ` Jens Axboe
2014-10-02 18:21 ` Elliott, Robert (Server Storage)
2014-10-02 18:32 ` Jens Axboe
2014-10-02 18:41 ` Jens Axboe
2015-04-03 18:13 ` Elliott, Robert (Server Storage)
2015-04-03 18:24 ` Jens Axboe
2015-05-12 15:32 ` Jens Axboe
2015-05-12 16:34 ` Elliott, Robert (Server Storage)
2015-05-12 17:56 ` Jens Axboe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox