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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.