Flexible I/O Tester development
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: "Elliott, Robert (Server Storage)" <Elliott@hp.com>,
	"fio@vger.kernel.org" <fio@vger.kernel.org>
Cc: Sitsofe Wheeler <sitsofe@gmail.com>, Jon Tango <cheerios123@outlook.com>
Subject: Re: linux /dev and normal files
Date: Wed, 01 Oct 2014 18:58:09 -0600	[thread overview]
Message-ID: <542CA321.5090608@kernel.dk> (raw)
In-Reply-To: <94D0CD8314A33A4D9D801C0FE68B402958CC85F9@G4W3202.americas.hpqcorp.net>

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



  reply	other threads:[~2014-10-02  0:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542CA321.5090608@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=Elliott@hp.com \
    --cc=cheerios123@outlook.com \
    --cc=fio@vger.kernel.org \
    --cc=sitsofe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox