fsync(1) patch to do DIOCGFLUSH on character devices

[Julian Hsiao]

Konstantin Belousov <kostikbel <at> gmail.com> writes:

> On Sun, Jul 24, 2016 at 03:04:34AM +0000, Julian Hsiao wrote:
>
>> The fsync(1) utility is a simple wrapper around fsync(2), but I didn't
>> find a similar utility for calling ioctl(DIOCGFLUSH) for character
>> devices.
>
> It is not similar in any reasonable interpretation of the word.

Would you agree that fsync(1) is to fsync(2) as printf(1) is to printf(3)?
If so, they are "similar" in the sense that they are wrappers of functions
they're named after. There's no ioctl(1) AFAIK.

>> fsync(2) is a no-op on character device files, which is a little
>> surprising but makes sense I suppose (would raising EINVAL be against
>> POSIX?).
>
> POSIX does not mention special nodes at all, so the implementation is
> free to do whatever it wants/needs.

Right, I'm just half wondering out loud why it doesn't raise EINVAL. Hmm, I
suppose prior to devfs(5), calling fsync on device files could be
meaningful.

>> However, conceptually the goal is the same: commit writes to permanent
>> storage, so here's a small patch to fsync(1) that calls
>> ioctl(DIOCGFLUSH) for character device files instead.
>
> This ioctl() does not perform what you describe, at least not on the
> level of the buffer cache/page cache for the device. It is the duty of
> the filesystem (or other in-kernel consumer) to ensure that cache is
> flushed when needed.
>
> The ioctl only sends BIO_FLUSH command to the driver, which does
> something to the hardware. Often this 'something' is either nop or have
> no observable implications.
>
> That said, I do not see the proposed change as useful.
 
Yes, I understand the distinction. One flushes the kernel buffer cache,
while the other flushes the hardware cache, lying HBAs / HDDs / SSDs
notwithstanding. I was looking for a quick way to test BIO_FLUSH in my own
code, and I was too lazy^W^Wdidn't have time (nor need) to write a
full-blown ioctl(1) utility. So it's useful to me, and I thought maybe some
people would too, so thought I'd share. I figure the audience of fsync(1)
wouldn't be confused by the overloading.

Julian Hsiao