On Thu, Oct 27, 2016 at 05:22:14PM -0700, Jeremy Allison via samba wrote:> > Looking around inside that source code I also see: > > do_read (GVfsBackend *backend, > GVfsJobRead *job, > GVfsBackendHandle handle, > char *buffer, > gsize bytes_requested) > { > GVfsBackendSmb *op_backend = G_VFS_BACKEND_SMB (backend); > ssize_t res; > smbc_read_fn smbc_read; > > /* libsmbclient limits blocksize to (64*1024)-2 for Windows servers, > * let's do the same here to achieve reasonable 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 reads / writes. > > Restricting this to 65534 is *insane* and slow. That > whole chunk of code restricting the size needs to be > removed.Oh it's my fault from 2009: https://bugzilla.gnome.org/show_bug.cgi?id=588391#c10 :-). I'll log another bug to get the whole thing removed now we pipeline correctly.
On Thu, 27 Oct 2016 17:30:09 -0700, Jeremy Allison <jra at samba.org> wrote :> On Thu, Oct 27, 2016 at 05:22:14PM -0700, Jeremy Allison via samba > wrote: > > > > Looking around inside that source code I also see: > > > > do_read (GVfsBackend *backend, > > GVfsJobRead *job, > > GVfsBackendHandle handle, > > char *buffer, > > gsize bytes_requested) > > { > > GVfsBackendSmb *op_backend = G_VFS_BACKEND_SMB (backend); > > ssize_t res; > > smbc_read_fn smbc_read; > > > > /* libsmbclient limits blocksize to (64*1024)-2 for Windows > > servers, > > * let's do the same here to achieve reasonable 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 reads / writes. > > > > Restricting this to 65534 is *insane* and slow. That > > whole chunk of code restricting the size needs to be > > removed. > > Oh it's my fault from 2009: > > https://bugzilla.gnome.org/show_bug.cgi?id=588391#c10 > > :-). > > I'll log another bug to get the whole thing removed > now we pipeline correctly.I just tried and when I limit samba to SMB2 connections (in smb.conf), Nautilus/gvfs cannot connect (it doesn't even see the share). I also tried starting a discussion on the topic yesterday: https://mail.gnome.org/archives/gvfs-list/2016-October/msg00000.html It seems that Ross Lagerwall started working on the topic a while ago, but I don't know when/how the code will be included. Thanks for your help !
On Fri, Oct 28, 2016 at 08:18:19AM +0200, Saint Germain via samba wrote:> Nautilus/gvfs cannot connect (it doesn't even see the share). > > I also tried starting a discussion on the topic yesterday: > https://mail.gnome.org/archives/gvfs-list/2016-October/msg00000.html > > It seems that Ross Lagerwall started working on the topic a while ago, > but I don't know when/how the code will be included. > > Thanks for your help !Can you get a debug level 10 log when you try to connect using smb2+ and gvfs ? That should just work.
Am 28.10.2016 um 08:18 schrieb Saint Germain via samba:> On Thu, 27 Oct 2016 17:30:09 -0700, Jeremy Allison <jra at samba.org> > wrote : > >> On Thu, Oct 27, 2016 at 05:22:14PM -0700, Jeremy Allison via samba >> wrote: >>> Looking around inside that source code I also see: >>> >>> do_read (GVfsBackend *backend, >>> GVfsJobRead *job, >>> GVfsBackendHandle handle, >>> char *buffer, >>> gsize bytes_requested) >>> { >>> GVfsBackendSmb *op_backend = G_VFS_BACKEND_SMB (backend); >>> ssize_t res; >>> smbc_read_fn smbc_read; >>> >>> /* libsmbclient limits blocksize to (64*1024)-2 for Windows >>> servers, >>> * let's do the same here to achieve reasonable 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 reads / writes. >>> >>> Restricting this to 65534 is *insane* and slow. That >>> whole chunk of code restricting the size needs to be >>> removed. >> Oh it's my fault from 2009: >> >> https://bugzilla.gnome.org/show_bug.cgi?id=588391#c10 >> >> :-). >> >> I'll log another bug to get the whole thing removed >> now we pipeline correctly. > I just tried and when I limit samba to SMB2 connections (in smb.conf), > Nautilus/gvfs cannot connect (it doesn't even see the share). > > I also tried starting a discussion on the topic yesterday: > https://mail.gnome.org/archives/gvfs-list/2016-October/msg00000.html > > It seems that Ross Lagerwall started working on the topic a while ago, > but I don't know when/how the code will be included. > > Thanks for your help ! >gvfs connects with smb2 here with these settings on the client's smb.conf client max protocol = SMB2_10 client min protocol = SMB2_10