linux-kernel - Re: Block-level access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGA4w7kD6KK-bW=HjQTOCgyG1thtz7WKm=nTv__2xZSYzZKvvA@mail.gmail.com>
Date:   Fri, 2 Sep 2016 09:24:38 -0500
From:   Alex Austin <aaustin@...antechonline.com>
To:     Bart Van Assche <bart.vanassche@...disk.com>
Cc:     linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
        linux-block@...r.kernel.org
Subject: Re: Block-level access

My access is almost purely sequential and primarily writing, so read-ahead
doesn't help me. What's problematic with pread/pwrite is the lack of error
channel from media errors.

BSG looks very interesting. I'll look further into that today.

On Thu, Sep 1, 2016 at 5:16 PM, Bart Van Assche
<bart.vanassche@...disk.com> wrote:
> On 09/01/2016 02:48 PM, Alex Austin wrote:
>>
>> CC'ing linux-scsi and linux-block.
>>
>> Also, please CC me in replies.
>>
>> On Thu, Sep 1, 2016 at 4:43 PM, Alex Austin <aaustin@...antechonline.com>
>> wrote:
>>>
>>> Hello,
>>> What is the most performant way to directly interface with an attached
>>> hard
>>> drive? I've so far used read()/write() on /dev/sd_ but I find error
>>> handling
>>> exceedingly difficult, as I don't always even get errors reported, even
>>> if the
>>> open() call includes O_DIRECT. I've also used ioctl(SG_IO), but find that
>>> it's
>>> extremely slow due to the lack of queuing support in the API. Is there a
>>> mid-level API that will get me decent error handling while allowing
>>> command
>>> queuing, or do I just need to make multiple threads all doing separate
>>> SG_IO
>>> ioctls?
>
>
> What the most efficient way is to interface is with a hard drive depends on
> the I/O pattern. Are you aware that buffered I/O performs read-ahead? Have
> you already tried to tune the read-ahead setting (blockdev --getra /
> blockdev --setra)?
>
> BTW, if you need an example of how to queue SG_IO, you are welcome to have a
> look at the fio source code. You will probably be interested in the bsg API.
> See e.g. https://lwn.net/Articles/174469/.
>
> Bart.



-- 
Intelligence is knowing that a tomoato is a fruit; wisdom is knowing
that it doesn't go in a fruit salad; charisma is selling a
tomato-based fruit salad.