Page MenuHomeFreeBSD

Complete support for IO_APPEND flag in fuse
ClosedPublic

Authored by cem on Jun 25 2017, 2:27 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 5 2024, 11:17 PM
Unknown Object (File)
Jan 14 2024, 11:30 AM
Unknown Object (File)
Dec 20 2023, 4:24 AM
Unknown Object (File)
Oct 5 2023, 3:26 PM
Unknown Object (File)
Sep 11 2023, 4:45 AM
Unknown Object (File)
Sep 6 2023, 4:21 PM
Unknown Object (File)
Sep 2 2023, 6:47 AM
Unknown Object (File)
Aug 27 2023, 6:44 AM
Subscribers
None

Details

Summary

This finishes what r245164 started and makes open(..., O_APPEND) work again
after r299753.

  • Pass ioflags, incl. IO_APPEND, down to the direct write backend (r245164 added it to only the bio backend).
  • (r299753 changed the WRONLY backend from bio to direct.)

PR: 220185
Reported by: Ben RUBSON <ben.rubson at gmail.com>

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Fix looks good to me. I didn't realize that direct I/O could be happening on
multiple descriptors concurrently, so this would be needed.

Good catch.

This revision is now accepted and ready to land.Jun 25 2017, 12:35 PM

direct I/O could be happening on
multiple descriptors concurrently, so this would be needed.

It's not a race condition; it happens even with a single descriptor. Just a logic bug where IO_APPEND wasn't getting passed into and handled by the direct write path.

Ok, yes. I was assuming that direct I/O of a single thread would be sequentially
increasing writes that would remain in order (ie. all would grow/append to the
file).

This revision was automatically updated to reflect the committed changes.