Re: [PATCH 0/4] Generalize zonemode=zbd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/7/20 9:53 PM, Damien Le Moal wrote:
On 2020/04/08 10:08, Vincent Fu wrote:
On 4/7/20 9:00 PM, Damien Le Moal wrote:
On 2020/04/08 9:07, Vincent Fu wrote:
On 4/7/20 4:48 PM, Jens Axboe wrote:
   > On 4/6/20 6:58 PM, Damien Le Moal wrote:
   >> This series extend support for zonemode=zbd beyond Linux only and as is
   >> allows the use of this zonemode on any platform with regular block
   >> devices. The same also applies to Linux systems that do not have zoned
   >> block device support (e.g. enterprise distributions with kernels version
   >> lower than 4.10). For zoned block device support, Linux implementation
   >> is preserved. Other OS specific code can be added with automatic
   >> configuration with the configure script to add zoned block device
   >> support.
   >>
   >> Additionally, ioengine operations are updated to allow an IO engine to
   >> provide implementations for the zone operations needed to support zoned
   >> block devices. This is convenient for cases where the system OS/kernel
   >> does not have any support implementation available.
   >>
   >> Finally, the libzbc IO engine is introduced to support zoned block
   >> devices on Linux distributions without native kernel level support (E.g.
   >> RedHat/CentOS). SImilarly to the sg ioengine, this new IO engine usesi
   >> passthrough commands implemeted by libzbc API to directly access SMR
   >> drives.
   >
   > Looks ok to me, I've applied it. But please send a job file that uses
   > it as well to put in examples/, thanks.
   >

The AppVeyor Windows builds fail due to the zbd changes:

https://ci.appveyor.com/project/axboe/fio/builds/32024485

configure reports:

Zoned block device support    no
libzbc engine                 no

but nevertheless an attempt is made to build the zbd code.

With the changes, zbd.c should be compiled for any OS to enable zonemode=zbd
with regular block devices. But oslib/linux-blkzoned.c should not be compiled.
What is the compilation error ? Is it something in zbd.c ?
I do not have any Windows machine to test builds.



This is the error:

      CC zbd.o
In file included from zbd.c:10:0:
os/windows/posix/include/dirent.h:8:2: error: unknown type name ‘ino_t’
    ino_t  d_ino;     /*  File serial number */

zbd.c includes dirent.h which I think result in this error for windows. But
zbd.c actually does not use d_ino anywhere and removing the dirent.h include
from it is fine (just checked on Linux).

    ^~~~~
zbd.c: In function ‘zbd_unaligned_write’:
zbd.c:1242:7: error: ‘EREMOTEIO’ undeclared (first use in this function)
    case EREMOTEIO:
         ^~~~~~~~~
zbd.c:1242:7: note: each undeclared identifier is reported only once for
each function it appears in

OK. This one should be easy to fix.


Here is the automated Windows build:

https://ci.appveyor.com/project/axboe/fio/builds/32024485/job/wmff344x9q4j09iq

The macOS build now also fails with a similar error:

https://travis-ci.org/github/axboe/fio/jobs/672273652

Sending a patch right away. If you could test builds with it, that would be
great. Thanks !



For what it's worth, I have integrated AppVeyor and travis-ci with my own github account, allowing the two services to run through the build/test cycle on Linux, Windows, and macOS any time I push changes to my fork of fio.

It's been a while since I set up the integration but it looks like the right places to look are here:

https://github.com/marketplace/appveyor
https://github.com/marketplace/travis-ci

The main drawback of the two services is that they do not provide access to the test artifacts. So I maintain a small cluster of servers that does automated builds/testing for fio, although this is all going away when our lab is dismantled at the end of May.



[Index of Archives]     [Linux Kernel]     [Linux SCSI]     [Linux IDE]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux