Flexible I/O Tester development
 help / color / mirror / Atom feed
* 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