On Tue, Jan 25, 2022 at 09:09:36PM +0100, Ralph Boehme wrote:>On 1/25/22 01:50, Christof Schmitt wrote: >>FWIW, preadv2() has RWF_DSYNC and RWF_SYNC which provide O_DSYNC and >>O_SYNC semantics per write. Maybe one of those aligns more closely with >>WRITE_UNBUFFERED. > >perfect! Any takers? :)Hmmm. How to add the in_flags field for the SMB_VFS_PREAD_SEND/SMB_VFS_PWRITE_SEND ? Both take an fsp, so is this something we should be adding to the files_struct as a structure element (or a one element in the fsp_flags bitfield) or as a separate 'flags' parameter to the VFS calls ? Personally I prefer adding to the files_struct as that way it's available to all handle-based VFS calls and we don't have to change SMB_VFS_PREAD_SEND/SMB_VFS_PWRITE_SEND, and can just make use of the feature inside vfs_default.c on platforms that have it.
On 1/25/22 21:45, Jeremy Allison wrote:> Hmmm. How to add the in_flags field for the > SMB_VFS_PREAD_SEND/SMB_VFS_PWRITE_SEND ? > > Both take an fsp, so is this something we should be adding > to the files_struct as a structure element (or a one element > in the fsp_flags bitfield) or as a separate 'flags' parameter > to the VFS calls ?I think we should bite the bullet and add the flag as parameter to the VFS calls and not mess with the fsp handle. -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20220125/ed7fd976/OpenPGP_signature.sig>
On Tue, Jan 25, 2022 at 12:45:07PM -0800, Jeremy Allison wrote:> On Tue, Jan 25, 2022 at 09:09:36PM +0100, Ralph Boehme wrote: > > On 1/25/22 01:50, Christof Schmitt wrote: > > > FWIW, preadv2() has RWF_DSYNC and RWF_SYNC which provide O_DSYNC and > > > O_SYNC semantics per write. Maybe one of those aligns more closely with > > > WRITE_UNBUFFERED. > > > > perfect! Any takers? :)Strictly speaking, WRITE_THROUGH would match the SYNC flag (write the data to stable storage). WRITE_UNBUFFERED implies writing to storage, but ensure that there is no data buffered, which has no Linux/POSIX equivalent call (to my knowledge). So smbd sets write_through for both of the flags.> Hmmm. How to add the in_flags field for the SMB_VFS_PREAD_SEND/SMB_VFS_PWRITE_SEND ? > > Both take an fsp, so is this something we should be adding > to the files_struct as a structure element (or a one element > in the fsp_flags bitfield) or as a separate 'flags' parameter > to the VFS calls ? > > Personally I prefer adding to the files_struct as that way it's > available to all handle-based VFS calls and we don't have > to change SMB_VFS_PREAD_SEND/SMB_VFS_PWRITE_SEND, and can > just make use of the feature inside vfs_default.c on > platforms that have it.This flag is specific for the individual write request (passed through smbd_smb2_write_state to schedule_aio_smb2_write). No other operation than the write has the flag, so having it in files_struct seems a bit misplaced. Maybe adding a flags field to pwrite_send would be better? Christof