search for: smbcfile

...able performance. (#588391) > * > * TODO: port to pull mechanism (#592468) > */ > if (bytes_requested > 65534) > bytes_requested = 65534; > > smbc_read = smbc_getFunctionRead (op_backend->smb_context); > res = smbc_read (op_backend->smb_context, (SMBCFILE *)handle, buffer, bytes_requested); > > which is also completely broken and wrong. The read call > can take any arbitrary size and the both the libsmbclient > SMB1 and SMB2 engines will break this down into as many > simultaneous on the wire calls as needed to pipeline > the read...

On Thu, 27 Oct 2016 16:57:13 -0700, Jeremy Allison <jra at samba.org> wrote : > On Fri, Oct 28, 2016 at 01:42:35AM +0200, Saint Germain via samba > wrote: > > On Thu, 27 Oct 2016 16:27:05 -0700, Jeremy Allison <jra at samba.org> > > > if you see any of these then it happened. > > > > Ok I understand how to check that it happened, but how can I make

Dear Gents, We are using libsmbclient smbc_getFunctionRead to read from a Microsoft DFS share. Before each 64k read there are a QUERY_PATH_INFO and a GET_DFS_REFERRAL which slow down the transmission. Is there a way to query these only once at the beginning of the transmission and cache it? system: 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux lib:

...e SMB1 to > connect, so there is no chance to trigger a server-side copy. Oh, just checked the current gvfs source code to copy an smb file. It does: static gboolean copy_file (GVfsBackendSmb *backend, GVfsJob *job, const char *from_uri, const char *to_uri) { SMBCFILE *from_file, *to_file; char buffer[4096]; size_t buffer_size; ssize_t res; char *p; gboolean succeeded; smbc_open_fn smbc_open; smbc_read_fn smbc_read; smbc_write_fn smbc_write; smbc_close_fn smbc_close; from_file = NULL; to_file = NULL; succeeded = FALSE; smbc_open =...

...: port to pull mechanism (#592468) >>> */ >>> if (bytes_requested > 65534) >>> bytes_requested = 65534; >>> >>> smbc_read = smbc_getFunctionRead (op_backend->smb_context); >>> res = smbc_read (op_backend->smb_context, (SMBCFILE *)handle, >>> buffer, bytes_requested); >>> >>> which is also completely broken and wrong. The read call >>> can take any arbitrary size and the both the libsmbclient >>> SMB1 and SMB2 engines will break this down into as many >>> simultaneous o...

...a QUERY_PATH_INFO and a > > GET_DFS_REFERRAL which slow down the transmission. Is there a way to > query > > these only once at the beginning of the transmission and cache it? > > Hmmm. This seems to be done inside : > > SMBC_read_ctx(SMBCCTX *context, > SMBCFILE *file, > void *buf, > size_t count) > > where it's doing: > > status = cli_resolve_path(frame, "", context->internal->auth_info, > file->srv->cli, path, >...

...* > > * TODO: port to pull mechanism (#592468) > > */ > > if (bytes_requested > 65534) > > bytes_requested = 65534; > > > > smbc_read = smbc_getFunctionRead (op_backend->smb_context); > > res = smbc_read (op_backend->smb_context, (SMBCFILE *)handle, > > buffer, bytes_requested); > > > > which is also completely broken and wrong. The read call > > can take any arbitrary size and the both the libsmbclient > > SMB1 and SMB2 engines will break this down into as many > > simultaneous on the wire calls...

...468) > >>> */ > >>> if (bytes_requested > 65534) > >>> bytes_requested = 65534; > >>> > >>> smbc_read = smbc_getFunctionRead (op_backend->smb_context); > >>> res = smbc_read (op_backend->smb_context, (SMBCFILE *)handle, > >>> buffer, bytes_requested); > >>> > >>> which is also completely broken and wrong. The read call > >>> can take any arbitrary size and the both the libsmbclient > >>> SMB1 and SMB2 engines will break this down into as many &g...

...t; */ >>>>> if (bytes_requested > 65534) >>>>> bytes_requested = 65534; >>>>> >>>>> smbc_read = smbc_getFunctionRead (op_backend->smb_context); >>>>> res = smbc_read (op_backend->smb_context, (SMBCFILE *)handle, >>>>> buffer, bytes_requested); >>>>> >>>>> which is also completely broken and wrong. The read call >>>>> can take any arbitrary size and the both the libsmbclient >>>>> SMB1 and SMB2 engines will break this down...